It seems like a problem of the past, but you can still run into specifically compiled 32 and 64bit dlls1. This results in an issue if you still want (or need) to support the 32bit NAV Windows Client. Or at least I thought it would result in a problem but as Arend-Jan Kauffmann (highly recommended blog author and MVP) quickly pointed out, it actually isn’t: You just put both dlls in your Add-Ins folder and allow the Client to pick the right one!
It has been very quiet at my blog for the last two months. The main reason for this is the go-live of a big NAV2016 upgrade I’ve been working on for the last half year or so.
This blog is related to this project. We are using some DLLs for this project. Among them are Anveo and ForNAV.
Okay here we go. In this post I deliver the promised code that handles automatic deployment of all your assemblies to client and server, as needed.
For any of you who haven’t read the last two posts, I am talking about automatically deploying .NET assemblies to clients and server, from the database, on demand, at runtime.
Let me tell you right away if you need to read this post at all. If you never wrote a single .NET class library intended to be used as a .NET interoperability assembly from C/AL, or if you never ever deployed a .dll file into the Add-ins folder of either Service or RoleTailored Client, then you probably don’t want to read this post.
Sometimes, you have multiple NAV Instances installed. When you have multiple installations, with different builds, you cannot use the PowerShell functions for each instance.
You could try loading the NavAdminTool.PS1 in the correct NST folder. However, this will probably not even work.
With Microsoft Dynamics NAV 2015 there comes one feature in Add-In files area – you do not need manually to copy add-in dll to client: when client doesn’t find it, NAV copies add-in from server.
It is very good: If you’ve installed NAV client on some computer, you don’t care about all add-ins, when user needs it, he will have it.