Install from .vsix

This is a quick blog about installing the AL language for Visual Studio Code from a .vsix file.

When you create a developer preview Azure VM for AL development, you get a landing page to access this VM. The script that creates this VM will put all the components on the VM that you need to do your development, including the correct version of the AL Language extension for VS Code.

If you want to do your development locally, you will need to put the right version of the AL Language extension on your local installation of VS Code. Lucky for you, there is a link on the landing page for your VM that will download the installation package into your downloads folder. The file has the extension .vsix, which is what VS Code needs.

All you need to do is press Ctrl+Shift+P and type ‘vsix’ in the command palette, and VS Code will suggest ‘Extensions: Install from vsix…’. When you select this, you need to browse to the file, and hit the ‘Install’ button. If you already have another version of the AL Language installed, you’ll need to disable that, so that there is no confusion about which one VSCode uses.

Announcing NAV 2018

Real quick one today – James Phillips announced General Availability of Microsoft Dynamics NAV 2018.

Marko announced it on TwItter:

Which was retweeted by just about everyone I know. Promise made at the closing keynote at Directions in Orlando is hereby delivered!

Can’t wait to see when they announce “Tenerife”.

NAV Techdays 2017 Recap

My favorite week of the year has just ended. I’m in the high speed train from Antwerpen back to Amsterdam, which is over just like that so I don’t have much time to make this anything elaborate.

As per usual, the organization was superb. The venue is fantastic, with a great expo area, lots of good food and drink choices, and the seats in the great rooms are just about the most comfortable seats you can imagine. The Kinepolis is a movie theater that you can also rent for events. I think I speak for everyone when I say this is one of the most important features, and I hope we will never have to move to a different location.

My week started with a full day pre-conference workshop about automated testing in NAV. This workshop was hosted by none other than Luc van Vugt, who, as per usual, delivered a solid day of learning. I had misread the workshop description and the correspondence that we had prior to the workshop, so I did not get everything out of it that I could have, but Luc was so kind to offer assistance to me so that I could do the exercises at home. Any time you have an opportunity to train under Luc, you should take it.

My company, Cloud Ready Software, was a sponsor, so we had a booth to staff. It was a pleasure to be there and talk to anyone who had any questions about what we can offer.

As per usual, the two conference days were stuffed with 90 minute deep-dive sessions on any topic you can think of. My favorite ones were Waldo’s “Rock ‘n Roll with VS Code”Anders and Nikola’s “Creating great APIs”, and the Docker session by Freddy, Tobias and Jakub. Fortunately for you, you can watch all of the sessions on YouTube, Luc had all of them uploaded within a week of the conference.

I can’t say enough about this conference. For any technical resource in the NAV channel (and I include Dynamics 365 for Finance and Operations in that category), NAV Techdays is a must to attend, every single year. This is the second time that I’ve gone, and I am still kicking myself for not going the first few years. If I can help it, I will not make that mistake again.

See you next year in Antwerpen!

Directions 2017 EMEA Recap

After a supremely busy week, with lots of last minute session and workshop work, I’m getting ready to go sightseeing in Madrid with my wife and some dear friends. This week has been frustrating, as well as satisfying, as well as educational, although not as educational as I would have wanted because I was too busy doing sessions and workshops to have any time to attend any myself.

One of the key takeaways is that Microsoft is going to release NAV 2018 in December this year, so 4-5 months ahead of the spring release of “Tenerife”. The whole white label thing seems to be gone altogether, so partners can continue to use the Microsoft name in their marketing for their Dynamice 365 products. Still, there is some need for clarity about licensing, and about the long term future.

What everybody needs to acknowledge is that we now live in a world that is being disrupted continuously. Today, Microsoft is heavily investing in their current roadmap, one that they feel very strongly will succeed in the long run. You must understand that this world is moving at the speed of light, and if something happens to our ecosystem, Microsoft WILL react. When they do, they will focus on what they feel is their best chance to survive in this changed world, so it is up to US to make that happen.

This slide was shown at one of the presentations, and it shows where Dynamics 365 “Tenerife” fits into our world. As you can see, it is just one of many boxes. If the surrounding boxes change, there may be a completely different role for “Tenerife”. It might very well happen that the market shifts in such a way that there won’t be a need for it at all. Given everything that I’ve seen this week, I think the “Tenerife” story is awesome, and we are going to absolutely crush it in terms of features and capabilities. What I don’t know is whether we can grow this cloud business enough to remain strong over the long term. The key though, is to fully embrace the entire picture, not just the ‘NAV’ part of it. The days of just ‘NAV’ are over, and they’re not coming back.

If anything, what I get out of this week is that we all must play a crucial part in the success of our entire market. WE the partner channel WITH Microsoft, NOT Microsoft alone, will determine the success of this market. If you want to be a part of this ecosystem, you better adapt and embrace what is here to stay. Fighting it is a losing cause, and you will be left behind.

I say we take a deep breath, a chill pill, we take a good look at what we have to do, and we roll up our sleeves and make it happen.

Directions NA 2017 Recap

It’s been quite a week at Directions in Orlando. I’ve written about the confusion in the halls of the JW Marriott Grande Lakes resort, and I wanted to follow up about the closing keynote, and share an article by Microsoft’s General Manager for Business Apps & Strategy.

First the closing keynote, which was a very impressive thing to behold. This week has given me even more respect for Marko Perisic than I already had, because of the way that he owned what he said during the opening keynote, the way he listened to the event attendees during a few Q&A sessions, and how he has taken responsibility to do something with the feedback that he’s received this week. I already knew how much he cares and how much his team cares. Over the past decade I’ve gotten to know many of them quite closely, and they are really a great group of people that have their hearts in the right place. We are in good hands with them.

So, there are 4 items on the todo list:

  1. The ‘white label thing’ is not going to work. We are Microsoft partners, and we need the Microsoft brand.
    • I think the white label thing got taken out of context a little bit. I know someone said “once you change 1 line of code you own the product” but of course it’s more complex than that.
    • The point is that this is a Microsoft product, and we create things to extend it. We add to it, but it is still a Microsoft ecosystem, and we need to be able to leverage that
  2. Delaying the release until spring is creating confusion, and the delay in decision is going to cost many partners a LOT of money. Marko has committed to see if he can fix that
  3. Non-NAV Partners have nothing to sell at the moment. Microsoft needs to be more clear about how non-NAV partners can move into Dynamics 365
  4. Microsoft needs to be crystal clear toward the user group, and there is a firm commitment to be more involved with the user groups

Now toward the end, Marko shared a picture of a word cloud. This was the result of an internal survey, where everyone in the NAV team expressed their feelings toward the product and the greater community. I don’t know about you, but this gets me going every time. If I may speak for myself: the feeling is mutual.

One other thing that was posted a couple of days after Directions was this:

I think that the whole “NAV is dead” thing was totally misunderstood. Maybe someone was talking about the name NAV, but I really don’t think it actually is dead, or even that there are plans to kill it. I do think Microsoft at the corporate level doesn’t always have a clue (which is a polite way of saying that it seems like sometimes they have no clue whatsoever), and I also think that one way or another there is going to be just one “ERP” in Dynamics 365.

Personally I think that the NAV flavor has a really good chance of being that one flavor. For sure we are NOT dead, and there is a LOT of really good and exciting stuff ahead of us.

 

What’s Going On Out There?

In case you missed it, there were some unexpected announcement this week at Directions North America in Orlando, and as a result there’s some growing trepidation among my people of the NAV partner channel.

Over the past few years, Directions North America has become the time when Microsoft announces the new version of Dynamics NAV. All year long, the partner channel goes out and tries to time sales around this time, and they make promises like “just wait for Directions, the new version will come out, and we can get your project started right away”. Usually, partners go to the conference, attend all the sessions they can catch, and on their way back home, they put in their license orders.

This year, however, the announcement was that there would be NO new version right at Directions. Microsoft is working on the next greatest cloud product, and they have not yet decided what to call it, how licensing will work. We are told that the code is ready to go, but they’re not yet ready to pull the trigger, mostly because of marketing reasons. Since Microsoft wants to go big bang with this new product (identical “full NAV” on premise as well as in the cloud).

This announcement was made by Marko Perisic during the opening keynote, and that afternoon there was a Q&A session that got quite heated. I was not present at the first one, but because it was so “popular” they decided to do a repeat, and of course I did go to the repeat.

At the same time, some event was taking place with some big shots from Microsoft and some inner circle partners, where someone said that someone else high up in Microsoft said that “NAV is dead”. When I heard this, I was immediately skeptical about the accuracy of the quote, and even if it was accurate, that it was probably (likely) taken out of context.

I listened to Marko do some damage control, and to a number of people put forward their points of view, which were made with varying degrees of validity. My takeaways of this session were these:

  • In My Humble Opinion – Marko made a big mistake by using the product codename in the official announcement. Granted, it was in quotation marks, but still, that was not a good thing. Now we have ‘NAV’, and we have “Tenerife” and we also have this unknown product name. Lots of lobbying by the way for ‘Dynamics 365 Navision’ which I actually like, but is probably too retro.
  • No new NAV version is a BAD BAD BAD thing. Postponing the release until spring 2018 is an even worse thing. Many people have been postponing sales for the new version, and not having this new product will defer revenue until spring of next year, and that is going to cost a LOT of people a LOT of money.
  • What I thought was an excellent suggestion was for Microsoft to release the product as it is today (after all, they DID say the code was ready to go), only for on premise, and use current licensing. That way we can start implementing the new product, and we can just call it NAV 2018 as everyone was expecting anyway
  • This rumor that “NAV is dead” must be dispelled at once. Nuff said.

This Q&A session was brutal, there was a LOT of anger in the room. But one thing that I also took away from that session is that we are SUPER lucky to have someone like Marko at the helm of this great team at Microsoft. I observed this guy talk to everybody at Directions, and he always had a smile while he was being chewed out. He’s a very direct person (which I actually appreciate a lot) and that can sometimes be misunderstood. I’m in a fortunate position to be one of the MVP’s, and we had a private meeting with Marko this evening. Because of NDA I can’t share what we discussed, but I can assure you that this guy cares deeply for this community of ours. I for one have gained a TON of respect for how he stood up and listened to everyone that wanted to talk to him. He has heard everyone, and has taken everything to heart.

It’s still the middle of the conference. I have lots of session/workshop stuff to work on, so I gotta get going. Can’t wait for the closing keynote.

Extensions V1 vs V2

You might have heard people talk about “Extensions v2”, and maybe that doesn’t make a whole lot of sense. Let me take a few minutes and try to explain the concept to you.

Back in 2015, Microsoft announced the concept of extensions to us, in this blog post. I remember reading this article, and being thoroughly confused. At the time I was not in a technical role, and I had let my technical knowledge slip for just a minute it seems.

Extensions v1

For extensions v1, development is done in good old C/SIDE. There are severe limitations as to what you are allowed to do. For instance, you cannot add values to option strings in table fields, and you cannot add code to actions on pages. I won’t get into the details of those limitations, but you must be aware of what you can and cannot do for extensions, because in C/SIDE you can do a LOT more than what you are allowed to do.

The extension itself is compiled in a so-called .NAVX file, also know as a NAV App file. To get to this package file, you must use PowerShell Cmdlets to export the original and modified objects, calculate the delta files, and then build the .NAVX file. To deploy this .NAVX file, you then must use another set of PowerShell Cmdlets.

Especially the development part can be cumbersome. There are many things you are not allowed to do, and as you build the .NAVX file, the system will yell at you when you did something wrong. There are many moving parts, and it takes a lot of discipline to get it right

Extensions v2

For extensions v2, development is done in Visual Studio Code (also known as VSCode), using the AL Language extension. Since you are no longer working in C/SIDE, only the allowable things are allowed. You simply cannot do anything that the tool is not capable of doing. You no longer have to export original objects and compare them to modified objects. Essentially, you are programming the delta files directly in VSCode.

Deploying the solution works simply by building the project from VSCode. You hit F5 and VSCode will build the package and deploys it to the service tier that you specify in the launch file. Deploying the app to a test system still happens with PowerShell Cmdlets.

Hopefully this clears it up a little bit. Once you understand the differences, it’s not so intimidating any longer.

Registered for NAV Techdays 2017

It’s that time of the year. The official announcement came in on Twitter that registration is open for NAV Techdays 2017, which is again held in Antwerp of course. The official two day conference is 16 and 17 November, but I consider the pre-conference workshops to be part of the event, so a full 4 days of deep technical knowledge sharing.

The session schedule has not been published, but we do know the pre-conference content, go take a look at the Sessions page to check out what is available to you. The familiar sessions will cover PowerShell by Waldo, JavaScript by Vjeko, automated testing by Luc van Vugt, SQL Server performance by Jörg, and of course the 2 day design patterns class by Mark. The new topics include how to SaaSify your software architecture, how to use Visual Studio Code (it is very important to learn about this one) and how to develop extensions with it by Arend-Jan. Another exciting one is the SCM workshop by Sören, he will show you how to make it work directly in VSCode.

Only a few regular sessions have been announced (some fantastic content by our friends at Microsoft), but I have a feeling that we will see a super deep dive into all things related to Dynamics 365. I cannot wait to go to Antwerp, and I hope to see you there.

Localize Objects with PowerShell and VSCode

In this article I will explain how you can use PowerShell to extract the right objects and merge those objects, and how to use Visual Studio Code to resolve most of the conflicts in the merged objects.

In a previous article, I explained how you can use PowerShell to create the environments. The script in this article actually use the variables that are assigned in the other one. What I should really do is create a configuration file and load that from both scripts. I wanted to share what I have so far though, without a handy configuration file but hopefully helpful nonetheless.

We start off with the 4 environments that were created in our last article: ORIGINAL, MODIFIED, TARGET, and RESULT. The first two environments contain the standard W1 and the ISV product. Target and RESULT are identical at this point, and they both contain the standard NA localization. All environments are in the same build number (NAV 2017 CU2 in this case). Because I have a developer license that has insert rights in the ISV number range, my strategy is to merge the product modifications into the NA database. If you do not have those insert rights, then a better strategy would be to merge the NA localization into the product environment instead. Microsoft has recently added insert capabilities for the standard object ranges to regular developer licenses, for this particular purpose. As I was working through the conflict objects of this assignment, I was thinking that this may even be the best default strategy anyway.

Due to a limited amount of time, and a limited amount of PowerShell skill, I decided to approach this task pragmatically:

  • Manually move the ISV specific objects to the RESULT environment
  • Use PowerShell to export all the objects
  • Manually eliminate the unmodified objects
    • NOTE: as I learned later, Waldo’s PowerShell modules actually have logic to remove these after the merge, so this can be scripted as well
  • Use PowerShell to merge the objects
  • Use Visual Studio Code (AKA VSCode) to resolve the conflicts as much as possible
  • Use PowerShell to join the objects
  • Use C/SIDE to resolve any remaining conflicts

The conflict resolution is something that has to be done manually. Everything else can be scripted in PowerShell. During this process I’ve asked Waldo for some help, and he explained that most of what I am doing here is already part of the merge sample scripts. In the Cloud Ready Software PowerShell module, there is a folder called “PSScripts”, and in that folder you will find a large number of scripts that you can use as an example to get started on your task. As you gain experience in using PowerShell, you will recognize a lot of useful features in those scripts, and you can modify them to your specific needs.

Alright, on to the details. The first part is to use PowerShell to extract the objects into their own folders. I also added commands to create the folder structure itself:

At this point, you will have an “Objects” folder in your working folder, with full object files for ORIGINAL, MODIFIED, and TARGET. Those object files have then been split into individual object files in the ORIGINAL, MODIFIED, and TARGET folders. Before using PowerShell to merge those objects, I used a text compare tool (I like Scooter Software’s Beyond Compare) to eliminate unmodified objects. Remember, I only want to work on the modified objects, so I don’t have to worry about getting confused by objects that were not changed for the ISV product.

Now that we only have modified objects in all three object folders, we’ll use the merge Cmdlet to do the actual merging of the objects.

If you notice, the output of the “Merge-NAVApplicationObject” Cmdlet is loaded into the variable “$MergeResult”. This object is then piped into the “Merge-NAVApplicationObjectProperty” Cmdlet. The first Cmdlet is a standard NAV PowerShell Cmdlet, and the second one comes with the Cloud Ready Software modules. The standard merge Cmdlet does not merge the Version List property, it simply takes the Version List from one of the three environments. We can have a discussion about whether the Version List is even important anymore, especially if you use Source Code Management. The reality is that most NAV developers depend on proper tags in the Version List, so it is useful to merge those as well. All you need to do is specify the prefixes that you want to merge (In my case NAVW1 and NAVNA) and it will find the highest value for those prefixes. All other prefixes will be simply copied into the RESULT objects.

At this point, we have all merged files in the RESULT folder. This includes the objects that were merged successfully, but also the objects that the merge Cmdlet could not resolve, for instance when code was added at the same position in MODIFIED and in TARGET. Since we are going to have to learn how to use VSCode, I decided to use that to resolve the conflicts.

With VSCode installed, you can open the RESULT folder and see the content of this folder inside the file browser at the left hand side. In the upper right hand corner is a button that you can use to split the screen into two (and even three) editor windows. This is very useful for resolving merge conflicts, because you can open the conflict file in one side, and the object file in the other side. You are editing the actual object file here, so you may want to take a backup copy of the folder before you get started.

Now what you must understand is that the conflict files only contains the pieces that the merge Cmdlet could not figure out. In a total of 860 objects, with 6956 individual changes, it was able to merge 96.4% of those changes. An object that may have 4 conflicts can also have a ton of other changes that the merge Cmdlet merged successfully. All YOU have to do is focus on the ones that need manual attention. For instance, codeunits 80 and 90 had a TON of modifications, but it only needed help with 3 of them.

I had a total of 115 conflict files, and I could completely resolve 112 of them in VSCode. I made a note of the few that remained, and decided to import those unchanged into C/SIDE, so I can finish those off in the proper IDE.

The last PowerShell command that I used is to create a single object file, which can then be imported into C/SIDE. Then I finished the last few remaining object files, and was able to compile all objects from there.

I’ve done many of these merges completely manually. To say that I was skeptical that PowerShell would do a good job is putting it mildly. I flat out did not trust the merge Cmdlet, surely they could not do as good a job as I could do. I was wrong. I checked a bunch of objects to see if I could find any mistakes and I could not find any. Not only did the merge Cmdlet do a fine job at merging the objects, it did so in about 5 minutes flat.

You can download the scripts here.

Instead of having to manually merge almost 900 objects, all I had to do was focus on the conflicts. Usually, a vertical merge like this would take me anywhere from 2 to 4 weeks, and I was able to finish this one in less than two days. Figuring out the PowerShell scripts took me much longer, but I will be able to use those for the next merge task.

Create NAV Environment with PowerShell

If you kind of know about PowerShell, and you want to use it more, but you don’t really know where to start, then you should read on. I am going to explain to you how you can use PowerShell to create the environments that you need to localize a product.

One of the things that always seem to fall on my plate at my job is to take an ISV product and merge that into the North American localization. I call it ‘localizing a product’. It is not, because localizing a product is much more than simply merging the objects, but it’s what you have to do first. I’ve done a bunch of these manually, and I kind of enjoy the almost mindless nature of the task of working my way through hundreds of objects (sometimes even thousands, I once ‘localized’ a product that had more objects than standard NAV itself).

This time around, I wanted to use PowerShell to automate as much as I could. Lucky for me, I attended Waldo’s “PowerShell Black Belt” workshop at NAV Techdays (read my review of this fantastic event here) and I should have all the tools to get this started.

The first thing you need is to install Waldo’s PowerShell modules, I will be using those for just about everything. I could figure out how to script all of this stuff myself, but why would I if Waldo already did that for us, and he is sharing his scripts. For instructions read Waldo’s blog here.

This post focuses on creating the environments themselves, and for this task you really need just a few things:

  • A SQL backup for the product in the W1 version of NAV, and make sure that you know exactly which build this was developed in. For instance, the product that I am working with was provided as a SQL Backup, and it was developed in NAV 2017 CU2.
  • The DVD’s for standard W1 and NA for the same NAV build.
  • A Development license that has insert rights for the product’s number range. If you only have a regular developer license, or if the ISV refuses to provide you with a license (this happens more often than not) then you will have to merge NA into the product database. This works exactly the same, you just have to figure out which environments are your ORIGINAL, MODIFIED and TARGET.

Use the NA DVD that you just downloaded and install the NA Version with a demo database. I like to give the database a meaningful name, so I called it ‘NAV2017NACU2’. This is all the manual installing that we will do, everything else is PowerShell baby! Actually, you could even use Waldo’s PowerShell modules to do the install as well. You could even write a script that downloads the DVD for you as well, all using Waldo’s PowerShell modules.

If you understand the mechanics of localizing a solution, you will know that we need 4 databases in total: standard W1, Product database in W1, standard NA, and a copy of the standard NA database that will become the product database. In this case, standard W1 is ORIGINAL; product W1 is MODIFIED; standard NA is TARGET and product NA is RESULT. This will become important when we do the merge, which will be another blog post.

Now the goal is to have a re-usable script, so we’ll use variables instead of having to re-type values multiple times, as you can see in the picture.

Remember, I installed standard NA. I created the working folder and placed the three backup files into the ‘Backups’ folder. I like to keep things together, but I can imagine having a network location for the standard backup files. The nice thing about using these variables is you can set them however you need them :). My database server is called KERPLUNK, which is just a regular unnamed instance on my VM called KERPLUNK. You could also use a demo installation and then you’d have to set it to ‘KERPLUNK\NAVDEMO’. I will use the 4 names for the database names as well as the service tier names.

The rest of the script is surprisingly simple to put together, here it is:

The reason why I start with the ‘Copy-NAVEnvironment’ step is because this script turns on port sharing for both server instances, so I don’t have to take care of that step myself. This is one of Waldo’s script that looks at the first server instance and creates a new one just like it. It creates a SQL Backup from the service instance, restores that into a new database, and finally it creates a new server instance for that new database, and it enables port sharing by default. The ‘New-NAVEnvironment’ is also one of Waldo’s scripts, and it does all the heavy lifting of restoring the database, creating the service tier and setting up port sharing. The full script took maybe 2-3 minutes to run for me, not bad for something that used to take all morning.

This same script could also be used to create your environments for developing extensions. For that you only need a standard database for ORIGINAL and a development database for MODIFIED, both of which will then be used to create the DELTA files for the extension package. If you look at the screenshot of my environment you’ll see an APPDEV and an APPTEST database. Both of these were originally created as copies of the standard database, also using PowerShell.

I’m planning to also put this into a video but I actually have this work to deliver so I’ll focus on that first. Up next is getting the objects out and comparing them to create a set of merged objects. Stay tuned!

Update 4/22/2017: added link to the new article about localizing the objects, and you can download the scripts here.