64-Bit Visual Studio Code Available

Beginning with the July 2017 update, Microsoft is now pushing out a 64-bit version of Visual Studio Code. If you have an existing 32-bit version installed, you will not automatically be updated to the 64-bit version.

All you need to do though is manually uninstall your 32-bit version and install the 64-bit one. All of your existing extensions will be picked up by the new version and should continue to work.

Grab the 64-bit version here.

Happy coding!

Advertisements

AL Language Extension in Marketplace

For those of you that have been trying out the Dynamics NAV Development Preview, you can now grab the AL language extension from the Visual Studio Code marketplace.

This will let you set up your local machine for coding and deploying extensions on the v2 platform. This version of the AL Language extension is not for coding against an on-prem NAV system. It requires a Dynamics 365 for Financials Sandbox tenant.

To get the AL Language extension, just do the following:

In Visual Studio Code, click the Extension icon at the left and in the search box at the top, type in AL

Capture.PNG

In the search results, select the AL Language extension, and click Install.

InstallAL

After it is installed, click the Reload button to reinitialize Visual Studio Code with your new extension.

ReloadAL

That’s it! You can now connect your AL Language extension to your sandbox environment and code away!

As always, happy coding!

NAV Development Tools – June/July Updates

I’ve been so busy actually using the new development tools, that I’ve not posted about them here.

Below is a quick rundown of recent updates to the new tools for building Dynamics NAV extensions using Visual Studio Code. All in all we are getting a ton of new features that are making this new platform something that is really exciting and fun to use!

June Update

Microsoft skipped an update in May in order to concentrate on squashing a load of bugs, and at the same time bring some very cool new features.

Highlights include:

  • Use the in-app designer to move cue tiles and cue groups on your role center
  • Create a new page in VS Code and then use the in-app designer to add controls. The changes will then be pulled back into VS Code!
  • Include translation and table data files with your extension.
  • Improved intellisense.

Microsoft also added the beginnings for tenant-specific profiles (eg. role centers), which is a major win for those of us that are building vertical solutions that require new roles.

Get more info on the June update here.

July Update

As we all should know by now, using .Net Interop with extensions v2 is a no-go. To address that, Microsoft is building some .Net functionality into the AL codebase. The July update brings us what Microsoft has called the most requested .Net replacement feature. More specifically……XML handling!

In standard AL code, you can now define the following data types:

  • XmlDocument
  • XmlAttribute
  • XMLElement

Other highlights include:

  • New objects types: Profile, Page Customization
    • use to deliver tenant-specific role and page customizations (eg. personalizations) with your extension!!!   FINALLY !!!!!!!
  • On screen syntax help for parameters.
  • The RecordRef data type can now be used (albeit only for tables less than 2 billion).
  • The Permission property can now be used. For now you can only use it to reference objects in your extension, but Microsoft has stated that this will change in the future.

Perhaps most importantly, there’s also been a refresh on the MSDN documentation. You can get to the updated docs here.

Get more info on the July update here.

Well…as you can see it’s pretty exciting to be a Dynamics NAV developer right now. There are so many cool new features being added to the new development platform every month. If you can spare any time at all, it is definitely worth spending some time trying out these new tools.

You can find out how to try this out here.

Happy coding!

NAV Supporter’s Blog

Back in February, Microsoft resurrected one of their old NAV developer blogs. It’s been renamed to the NAV Supporter’s Blog and as Microsoft puts it:

“This will be by and for people who support the Dynamics NAV products in one way or the other.”

This blog is not necessarily about new front-end features in the product, but more about tips and tools that can be used to better support and diagnose the product.

Recent posts include:
  • Multi-part series on a new NAV diagnostics toolkit
  • NAV performance troubleshooting
  • Build overviews for NAV 2013 –> 2017

The blog can be found here. Check it out!

Happy coding!

New Development Tools – April Update

As all Dynamics NAV developers probably know by now, Microsoft is working on the next generation of development tools for working with Dynamics NAV and Dynamics 365.

They’ve just released the April update, and included in this update is the tool to convert your v1 extensions to the new v2 format. Exciting!!!

Check out what else is new in the update here.

Find Out if an Extension is Installed, part 2

“Hi, this is Library, is Extension 1 home? What about Extension 2, are they home too?”

In my previous post on this topic, I explained how you can use the NAV App Installed App system table to see if a specific extension is installed. I later found out though that the ability to access that table may not always be available in the Dynamics 365 for Financials platform, so back to square one. I want a stable long-lasting solution.

Alas…events!

First…some background on why I need this functionality. I’m developing 2 extensions that share a common library, but I want to develop these extensions so that they are independent, meaning that a customer is able to install only one of the extensions if they choose to, and not be forced to install both. I also need certain features in each extension to act differently depending on if the other extension is installed or not. I know….never simple. 🙂

For those that are not aware, when you submit an extension to AppSource, you are able to submit along with it a library extension. Multiple extensions can be dependent on the same library, which makes it easy to deliver foundation type functions that are shared amongst your extensions. The library extension will not be seen in AppSource, but it will be automatically installed when any of the dependent extensions are installed.

What this also means is that when I am developing in the context of one of my “functional” extensions, I am able to directly reference objects that are contained in my library because the library is guaranteed to exist when the functional extension is installed. What I cannot do though is the opposite, because although the library extension knows that at least one functional extension was installed, it does not know directly which one it was. Make sense!? Clear as mud I know. 🙂

In the example below, let’s assume that I have a “Library” extension, and two functional extensions, brilliantly named “Extension 1” and “Extension 2”.

First, I need to create a codeunit in my library extension that will act as the “extension handler” so to speak. In other words it will house the functions required to determine what extensions are installed. In my library codeunit, I’ll add the following functions:

CheckIsExtensionInstalled(ExtensionAppID : GUID) : Boolean
IsInstalled := FALSE;
IsExtensionInstalled(ExtensionAppID,IsInstalled);
EXIT(IsInstalled);

GetExtension1AppID() : GUID
EXIT('743ba26c-1f75-4a2b-9973-a0b77d2c77d3');

GetExtension2AppID() : GUID
EXIT('a618dfa7-3cec-463c-83f7-7d8f6f6d699b');

LOCAL [IntegrationEvent] IsExtensionInstalled(ExtensionAppID : GUID;VAR IsInstalled : Boolean)

The above functions allow me to call into the codeunit to determine if either of my functional extensions are installed. The GUIDs that I used are samples above, but you should use the same GUID that is used in the corresponding extension manifest file.

The piece that makes this all possible is the published event IsExtensionInstalled. What I can do now is from within each functional extension, I can subscribe to that event so that each extension can basically give “answer” the library when it asks if it’s installed.

To do that, I create 2 more codeunits, one in each functional extension. These codeunits will contain a subscriber to the event that we published in the library codeunit. This way, if the extension is installed, its subscriber will respond to the event and let the library know that it is installed. If the extension is not installed then there won’t be anyone home to answer that call.

Extension 1

LOCAL [EventSubscriber] OnCheckIsExtensionInstalled(ExtensionAppID : GUID;VAR IsInstalled : Boolean)
IF ExtensionAppID = ExtensionHandler.GetExtension1AppID THEN
  IsInstalled := TRUE;

Extension 2

LOCAL [EventSubscriber] OnCheckIsExtensionInstalled(ExtensionAppID : GUID;VAR IsInstalled : Boolean)
IF ExtensionAppID = ExtensionHandler.GetExtension2AppID THEN
  IsInstalled := TRUE;

So how do we use all of this? Easy, of course. The example below shows code that you could use from either of the functional extensions, so that your extensions can act differently depending on what other extensions are installed.

IF LibraryCodeunit.CheckIsExtensionInstalled(LibraryCodeunit.GetExtension1AppID) THEN
  MESSAGE('Extension 1 is installed.');

IF LibraryCodeunit.CheckIsExtensionInstalled(LibraryCodeunit.GetExtension2AppID) THEN
  MESSAGE('Extension 2 is installed.');

There, easy right? If you want to try it out yourself, you can grab the above example on GitHub here.

Now, while you can do this if you own all of the source code for each extension, you cannot use this solution to determine if “any old random extension” is installed, as you need to add the subscriber function to the functional extension code. But, if you are developing out multiple extensions and if you need to know which of them are installed, then this solution will work wonderfully!

Happy coding!