NAV 2015 Automatic Deployment of .Net Assemblies

If you have already downloaded and installed NAV 2015 you should take a look at the Add-ins folder of the Windows Client. With NAV 2013 R2 we are used to an Add-ins folder that contains about 20 folders. But with NAV 2015 this folder is almost empty! Here is a screenshot of the Add-ins folder after a clean installation of NAV 2015:

What happened to the Add-ins? Are they discontinued? Or have Microsoft screwed up the installation? Not at all! The add-ins are still available as before.

So what’s going on here? Well, this is because NAV 2015 automatically deploys the add-ins when needed. Hurray! Yippee!

Let’s look how this automatic deployment works. (If you don’t want to read the whole story, just scroll down for the final give-away on .Net Interoperability)

In a nutshell

Add-ins are installed in the add-ins folder of the Dynamics NAV server and copied to the client on demand.

More in detail

You can extend the Microsoft Dynamics NAV server and the Windows Client with functionality that is available in Microsoft .Net Framework assemblies. The C/AL code can directly interact with .Net Framework objects, either from the .Net Framework class library or from your own custom assemblies. These assemblies can be used server side or client side. When using client side assemblies, they must be in the .Net Framework Global Assembly Cache or in the Add-ins folder. Normally the custom assemblies are installed in the Add-ins folder of the Windows Client.

Another option is extending the Windows Client with control add-ins. This is a custom control (visual element) that can be used to display data on pages in the Windows Client. The controls are delivered as .Net Framework assemblies and must be installed in the Add-ins folder of the Windows Client. More information about extending Microsoft Dynamics NAV with external components can be found here: http://msdn.microsoft.com/en-us/library/hh169423(v=nav.80).aspx. Or have a look at the blog of Vjeko for plenty examples of what is possible: http://vjeko.com/

The challenge with client-side assemblies was how to deploy them with as little disruption as possible to the user. The CfMD software test requires an installer for the client side assemblies, but many partners were struggling with the approach of an installer that user must run on their local computer before they could use their software. Some time ago, I published an example about how to automatically deploy assemblies, but still got many questions from people. So that approach wasn’t that easy either.

The steps to automatic deploy .Net assemblies with NAV 2015 are as follows:

1. Install the assemblies to the Add-ins folder of the Dynamics NAV server. Usually this is C:\Program Files\Microsoft Dynamics NAV\80\Service\Add-ins.
2. Declare a variable of type DotNet and set the RunOnClient property to Yes, or set the ControlAddIn property of a control on a Page.

When the Windows Client needs the assembly, it will follow the next steps:

1. Look in the Add-ins folder of the Windows Client for the assembly.
2. If not found, the Windows Client requests the assembly from the Dynamics NAV server and copy it in a subfolder of the %TEMP%\Microsoft Dynamics NAV\Add-Ins folder on the client computer.
3. If the Dynamics NAV server cannot find the required assembly the code will fail and an error occurs.

Important notes

Control add-in assemblies are searched client side by combining the ControlAddInExport attribute and the public key token, using reflection. But server side this could result in heavy processing. For this reason there is a new rule for naming control add-in assemblies: the name of the assembly file must exactly match the name as defined with the ControlAddInExport attribute within the assembly. For example: if your control add-in is named MyCompany.AddIns.SomeFantasticControl, then the assembly name has to be MyCompany.AddIns.SomeFantasticControl.dll

Does this break the possibility to combine multiple control add-ins in one assembly? No, that is still possible. You could use a dummy (invisible) control with the correct assembly name to download it or declare a client-side DotNet variable that references the same assembly as the control add-in to force the download.

Assemblies can be dependent of other files or reference other assemblies. The Windows Client will download the full content of the folder where the assembly is found. As a best practice, create a subfolder for each component and copy all needed files to this folder.

The name of the subfolder that is created in the %TEMP%\Microsoft Dynamics NAV\Add-Ins folder contains the version number of the assembly. If the version number changes, the Dynamics NAV server will automatically deploy the new version to the client the next time. The updated assembly will be stored in a new subfolder with the version number in the name. Previous versions of the assemblies in the %TEMP% folder are not automatically deleted. This must be done manually. But hey, it is a temporary folder, these folders tend to grow permanently…

The size of any file cannot exceed the Max Upload Size setting in the Dynamics NAV server configuration.

The file name of assemblies must comply with the Prohibited File Types setting in the Dynamics NAV server configuration.

A Windows Client that is deployed as ClickOnce Client will follow exactly the same flow. Which is great of course!

Development Environment

Some words about the Development Environment. Add-ins must be available locally, otherwise you cannot compile your objects. The Development Environment follows the same flow as the Windows Client. Assemblies are automatically downloaded from the server when needed.

The Assembly List, where you can pick the assembly that you want to use in your code, has a new Server tab. So you can browse the assemblies that are available on the server, even when they are not yet available client-side!

And you don’t need to set up the server name and port number in the Tools – Options menu, as long as a server instance is selected in the Tools – Database – Information window.

External component warning

Finally, one change with .Net Interoperability that really, really will make many people happy!

Know this message?

It has been removed in NAV 2015!