Blog

A few days ago I have published my PowerShell script that streamlines and automates deployment of control add-ins from Visual Studio. Over the past couple of days I have improved it a little bit, and fixed a few bugs, so here’s an updated version that is more resilient to your project structure, produces resource zips that NST not only extracts, but actually understands, and does a little more.

First, download the script by clicking here.

Now, what’s changed:

• Referencing NAV Extensibility assembly: depending on your project structure, the script was earlier unable to locate the assembly. It now attempts to look in paths relative to solution folder, project folder, and if all fails – it goes to the hardcoded location where the dll is most commonly located in default installs. And you can change this path easily if this location is different on your machine.
• Deploy to NST flag: the script can now deploy assemblies to the service tier, but only if you need it to. By default it does not. Deploying to service tier is useful if you are using strong-typed JSON-based communication between C/AL and JavaScript.
• Automatic creation of resource folder structure: if the script detects that your control add-in is of an interface type, it automatically creates the resource folder structure named after your exported control add-in name. For this to work, the default structure should exist in the _build\Resource subfolder of the project. I will soon post the whole control add-in project template that has this (and other things) included so the script will work right out of the box.
• Zipping: there seems to be a bug inside NST that does not allow ZIP files created using .NET built-in ZIP management features to be used as resources. Funny thing is – it allows you to import the assembly (it normally rejects files that are not valid zip), it properly extracts and reads the manifest, but it cannot access any scripts manifest references, for whatever reason. I’ll explain this issue in a separate post, and bring this to Microsoft’s attention as this should certainly be fixed. In the meanwhile, I found a workaround – you simply need to reference DotNetZip (Ionic.Zip) in your project. You can easily get it through nuget.

And yes, this script requires NAV 2016 to run, and to call it, use this post-build event:

set nst=DynamicsNAV90
powershell -ExecutionPolicy unrestricted -command "&'$(ProjectDir)_build\PostBuild.ps1' -DllFile '$(TargetPath)' -ServerInstance '%nst%' -ProjectPath '$(ProjectPath)' -SolutionDir '$(SolutionDir)' -Configuration '$(ConfigurationName)'"

All of this will probably make more sense to more of you once you get access to the whole Visual Studio project template, but for now – use the script, and let me know if it solves your day as it solves mine.