Three days of Visual Studio Code workshop in Stockholm, covering most aspects Visual Studio Code extensions for Dynamics NAV 2018 and Dynamics 365 Business Central.

I think we got around most by covering:

• The Visual Studio Code Editor
• Native Github integration
• Using Snippets
• Creating Snippets
• Converting existing objects to AL
• And of course, creating objects:
  • New Tables
  • Extending existing tables, including which properties can be changed and where to add code to triggers
  • New Pages
  • Extending existing pages, including which properties can be changed and where to add code to triggers
  • Creating codeunits, including:
    • Event subscriptions
    • Install Codeunits
    • Upgrade Codeunits
  • Creating reports in Dynamics 365 Business Central
  • Creating reports in Dynamics NAV 2018
  • Creating XML Ports
  • Creating Queries
  • Controlling the Departments menu
• Design patterns in Dynamics NAV/Dynamics 365 BC
• Using the Visual Studio Code editor with other extensions, like:
  • PowerShell
  • XML Documents
  • JSON Tools
  • Snippet Creator
• Upgrading to extensions

Thank you for making this an interesting three days with a lot of interest, feedback and questions.

The task

After the Dynamics NAV 2018 CU2 release, I found it safe to upgrade my own Dynamics NAV 2016 solution up to Dynamics NAV 2018. But not only that, ALL changed objects should be transferred to extensions.

My system is a small solution and it started in NAV 4.0. On every upgrade process, I have tried to kill all the changes in the system and to start all over, in order to utilize as much of the new standard functionality as possible. The upgrade process has been through a number of stages since 4.0:

4.0 -> 5.0

5.0 -> 2009

2009 -> RoleTailored 2009 R2

2009 R2 -> 2013

2013 -> 2016

2016 -> 2018 Extension V2.0

In short, I have taken all the beatings I possible could (maybe except the RoleTailored 2009 – I didn’t have the stomach for that), in order to experience what my customers would be going through later on.

Because of my conservative approach, there are only a limited amount of changes:

So, this should be a small and affordable solution to upgrade and here are my experiences.

The Upgrade

I found the upgrade procedure, which was very helpful, here:

https://docs.microsoft.com/en-us/dynamics-nav/upgrading-the-data

Firstly, the normal procedures:

• Backup of the database and restore a copy of the original, so that I would have that as a reference when I started changing the “live” database.
• I then installed the new Dynamics NAV 2018 CU2 in a side by side installation to have both versions available.
• Converting the database is usually the easiest task but this provided a bit more hassle than expected.
• Firstly, it is necessary to make sure that the data is opened as single user.
• Normally I just connect to the database with the development environment to convert it. But, here it is a bit more complicated. After a half hour of conversion, I got an error that the conversion could not be done with records in table 2000000100 Debugger Breakpoint. So, after deleting all records in the Debugger Breakpoint table (in SQL Server Management Studio – I didn’t have the patience to start everything up again and make a codeunit) I restarted the conversion.
• Next error was, that I didn’t have permission to modify the G/L Entry table (Yikes!).

The only solution is to upload a Developers License to the database and start over.

The big problem here, is that I have customers with add-on solutions from all over Europe. And I do not have one Developers License that covers all the objects.

• This means the following procedure is needed to convert the database:
  • Copy the data to temporary SQL tables
  • Delete all objects in that number series
  • Convert the database
  • Import the objects in the converted database (which is possible)
  • and lastly, copy the data back from the temporary tables.
• Next problem were add-on objects that were no longer included in the license but were left in the solution by the ISV. They had to be deleted.

This means that just converting the database can take as much as one whole day [:(]

The rest of the upgrade process with importing the upgrade objects and running the upgrade process were performed more or less as described in the Walk-Through from Microsoft.

In order to move the data from my tables in the 50.000-99.999 area to an extension, the next task was to rename all the old changed tables to be prefixed with the word “Old”. This is to ensure that I could have the new tables from the extensions with exactly the same name.

A tip is, to make sure that all tables, that are to be converted, are exported as Text before the renaming, otherwise it will be necessary to rename all table references later.

Now the new tables can be built.

The process I used was to export and convert all tables using the script described in my previous blog:

https://dynamicsuser.net/nav/b/peik/posts/converting-dynamics-nav-source-code-from-c-al-to-al-using-powershell

After the conversion, it is necessary to clean up the files, and it is recommended to start with the master tables, so they are available when cleaning the all other tables that reference them. Otherwise the Intellisense does not work. The cleaning consists of the following tasks:

• All object references must be changed from Table59000 or “59000” to the table name or page 59000 to page name

Or like here

• All conditions that contains field names with spaces, e.g. Document Type ,must manually be changed to “Document Type”.

• All conditions that contains Boolean variables must be changed from Yes/No to True/False

• Then all Text constants must be changed from the Textconst type to label

• And all CaptionML properties must be changed to Caption

And all other multilanguage captions must be removed to make it look like this:

• Then all Dot-Net variables must be identified.

In Dynamics NAV 2018 on-premise, it is possible to isolate the functions using dot-net in a codeunit developed in the C/Side Development Environment and call functions in that codeunit from the extension. That is not possible in Dynamics 365 “Tenerife”.

After this it is necessary to create an Install Codeunit to copy the data from the old tables to the new tables.

It is essential that this codeunit is built to be run multiple times. Otherwise the Install function will fail the second time it is installed.

In order to view both objects from the extension and from other objects in the 50.000-99.9999 object range, it is necessary to set up Dynamics NAV to run both C/Side and AL side-by-side. This is described here:

https://docs.microsoft.com/en-us/dynamics-nav/developer/devenv-running-cside-and-al-side-by-side

Otherwise it will not be possible to see both the old tables and the new tables defined in the extension.

The Result

I managed to create extensions for:

• 9 Codeunits including the Install Codeunit
• 7 Page Extensions
• 16 Pages
• 1 Query
• 4 Reports
• 5 Table Extensions
• 10 Tables

There were a number of objects that stayed in the C/Side Development Environment:

• 1 Query because the query from extensions cannot be used in Generic Charts
• 1 Codeunit that contains the functions using DotNet
• 1 Change to a standard table (Table 36) because of an error in the standard NAV code

The Next Upgrade

Luckily for me a new CU was released immediately after I upgraded to NAV 2018 CU2.

That meant that I could test the upgrade process.

So, now all I have to do is this:

• Download the new NAV 2018 CU3
• Close all running service tiers (2 separate servers)
• Uninstall NAV 2018 CU2 on both servers
• Install NAV 2018 CU3 on both machines
• Import the NAV 2018 CU3 objects in my database
• Compile all objects
• Build Server Application Objects
• Start all service tiers again

Done!

Installing the NAV 2018 CU3 objects also fixed the small error that prevented me from posting sales orders

So now I am down to only two changed objects in my database.

Nice

Converting from C/AL to AL can be a bit of a hassle:

• First you need to open den Development Environment
• Then filter the objects that needs converting
• Export the objects to a txt file in a folder
• Then Run the Txt2AL.exe
• Lastly import them in the workspace

So, I thought: Why cannot I do that directly from VS Code with PowerShell?

Searching the Internet, it seems that a lot of other people have struggled with the same issue so I decided to compile a PowerShell script that can be run directly from VS Code.

This should work:

Just remember:

• start VS Code as administrator
• load the PowerShell extension.
• Create a couple of folders
  • c:\temp
  • c:\temp\AL-Conversion
  • c:\temp\AL-Conversion\cal
  • c:\temp\AL-Conversion\al

And of course, change the connection details and filters.

Then just mark the code and press F8 to run the code.

The Script can be downloaded here:

http://ba-consult.dk/downloads/Convert_CAL_AL.zip

As usual, use at own risk [:)]

In the version 2.0 extensions of Dynamics NAV, there has been an insignificant flaw [H] When reinstalling an extension that contains new tables or new fields in existing tables.

The new data were deleted.

With the Dynamics NAV 2018 CU2 release, that has been corrected.

In order to test that, I have created a simple extension adding an extra table to Dynamics NAV: ShoeSize.

Apart from that, I have added a new field to the Customer table and Card page: “Shoe Size Code”.

The workspace looks like this:

Publishing and installing the extension, I can search for the “Show Size” page and create a new size:

I can add the size to customer 10000:

Previously after publishing and installing the extension, the data would disappear:

And the also from the Customer Card:

But in the CU2 version, now all data remains, even without the upgrade codeunits:

And the Customer Card:

So, now there are no more excuses, we can start creating real solutions with the customers.

According to a blog post from the Microsoft Dynamics development team:

https://docs.microsoft.com/en-us/dynamics-nav/extensions-upgrade-howto

It is now also possible to create upgrade codeunits to handle data to be changed during upgrade.