11. December 2016

Using 32 and 64bit DLLs in NAV 2017

It seems like a problem of the past, but you can still run into specifically compiled 32 and 64bit dlls¹. 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!

A bit more detail

You can test this by creating a solution with two assemblies, one targeting x64 and one targeting x86². Make sure both implement the exactly same interface, implicitly or explicitly. Also the assembly name, class name and namespace must be the same; projects obviously need to be different. After building your solution you get two dlls of the same name and public key token, but for different platforms. Now create a folder in your Server > Add-Ins folder and in there create two subfolders, e.g. x64 and x86 where you put the corresponding dlls. You can use the dll now as usual: Open the Dev Environment and reference the (Server) Assembly. As you will see, you actually get two references, one with Processor Architecture Amd64 and one with X86.

However, regardless which one you choose, you always get the following as Subtype for your variable:

As you can see, you have no more Processor Architecture in that link, and therefore it is valid for both. If you look into c:\<your user directory>\AppData\Local\Temp\Microsoft Dynamics NAV\Add-Ins\<build number>, you will notice that already the x86 version of your dll was transferred from the server which makes sense because finsql.exe still is 32bit. If you run whatever code is referencing the Assembly from the 64bit client, then that version is also downloaded and stored in that folder.

The code I used for testing

For those interested in the actual code, I kept it very simple. This is my C# class for 32 bit and the only change for 64bit is in line 16 where I obviously use “…compiled as 64bit”.

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
 
namespace Sample_32_64bit
{
    public class Hello
    {
        public string SayIt()
        {
            string env = "32";
            if (Environment.Is64BitProcess)
                env = "64";
            return "I am a " + env + "bit process and my library was compiled as 32bit";
        }
    }
}

I used a Codeunit to test this, which is even simpler:

OnRun()
Sample3264 := Sample3264.Hello();
MESSAGE(Sample3264.SayIt);

If I run this using Microsoft.Dynamics.Nav.Client.exe I get the following result as expected

And also no surprises when using Microsoft.Dynamics.Nav.Client.x86.exe

It might not always be that easy

While the test scenario was very straight forward and worked exactly as expected, the real library we wanted to use isn’t as easy because we have a x64 and a x86 dll but the Processor Architecture is not identified by the Dev Environment. Probably because of that NAV isn’t able to decide correctly which one to use and always downloads the x64 version³. But this can also easily be solved by just putting the right version in the client Add-In folder. I can’t imagine that anyone would use different dlls from the same machine. And even then very likely the problem is caused by a not so good compilation by the third party generating those dlls.

I have to say I like how easy NAV makes it for a developer to get this done correctly. What I thought would become a problem or at least a not so elegant solution turned out to be handled perfectly well by the platform. Thanks a lot again to Arend-Jan Kauffmann for pointing this out!

1. We need a library to send a pdf directly to a printer without converting it to an image or otherwise making a mess out of it. And it needs to work with large amounts of pdfs as well as with large pdfs. As it turns out, not that easy…
2. You can change that in Visual Studio 2015 in project settings > Build > Platform target
3. I would guess because x64 appears before x86 in the folder list, but I didn’t test it further

The Author

Tobias Fenster

Categories

C#, DLL, NAV

Tags

32bit, 64bit, processor architecture, x64, x86

Ein Kommentar zu “Using 32 and 64bit DLLs in NAV 2017”

1. Great post. Thanx for sharing.

   Log in to Reply