Dynamics NAV – Not All Assemblies are Created Equally

By Scott Frappier | November 9, 2015

Dynamics nav – not all assemblies are created equally

Recently, with a Microsoft Dynamics NAV 2015 implementation, we ran into an issue in which some functionality that had been created for Secure FTP integration did not work in the same fashion as it did in a prior version of Dynamics NAV (2009 R2) specifically.  When trying to compile the codeunit that managed the DotNET variables after upgrading the content that had been created, we received the following error:

Microsoft Dynamics NAV Development Environment

After validating that the add-in was installed in the proper “Add-in” folders of the Service Tier and RoleTailored Client, we went ahead and tried to browse to the DotNET variable and were able to successfully see it, but none of the methods or types were exposed:

.NET Type List

Mixed Mode Architecture – 32-bit Client/Development Environment, 64-bit Service Tier

When we originally developed this application, it was for a customer that was running Dynamics NAV 2009 R2.  We saw an advantage into designing the components so that we could easily transport them to the newer versions of NAV as the older Automation/ActiveX type variables were something that long-term were going to be a deprecated feature.  Sadly, at the older version, this type of issue did not occur and all of the methods were exposed when adding the .NET DLL file into the Add-ins folder:

.NET Type List

What we then determined, which is key to why this failed in the newer version of NAV but not in the older versions, revolves around how you compile and leverage your .NET assemblies. When looking at the .NET component, we noticed that it was compiled specifically for a processor architecture and was not compiled into MSIL (which is architecture independent):

Processor Amd64 in AX 2012

The developer of these components created the DLL file with a native implementation – meaning that the outer-layer of the DLL is considered managed code, but the internal aspect of it is still native code that is processor dependent.  Because we live in a mixed mode environment (even at NAV 2016 – the development environment is still 32-bit), the methods and classes exposed do not allow us to add this assembly for use – even the 32-bit implementation does not expose due to possible serialization restrictions on either the assembly, or potentially a requirement of the actual NAV .NET bridge components as well.

How Did We Fix It?

Our first instinct was to go down the path of leveraging ActiveX again – we weren’t excited at this prospect, so we contacted the developer of the solution that originally created the assemblies to see if MSIL was an option. The developer pointed us to the direction of a different implementation of the assemblies and we went ahead and created a new assembly that was MSIL equivalent (using Visual Studio 2015):

Assembly List

The methodology used in this new implementation of the product uses pure C# and leverages call-outs using P/Invoke to accomplish this task:

Microsoft Visual Studio

For the RTC Add-in Folder, we copied the newly created “pure C#” DLL into the add-ins along with the x86 native DLL that is called with P/Invoke – for the Service Tier, we copied the x64 native DLL (and our pure C# DLL) into it – that way, if we decided to run the component on the client, or on the server, it would invoke the correct architecture when processing:

Add-ins in Dynamics NAV

After successfully installing the component and doing a couple of updates on the DotNET assembly, our functionality worked as expected:

Edit WF Rec. in Dynamics NAV

Conclusion on Assemblies

The big lesson learned throughout this process is that you must be cognizant of the architectural differences between a 32-bit and 64-bit environment, as they have an effect on the results of how the DotNET variables work within Dynamics NAV. Moving forward, we will be ensuring that any .NET assembly that we use will require to be MSIL compatible, and if not compatible, that a MSIL shell is created with P/Invoke being used to call specific application functionality as needed within the assembly.

Special Thanks

I wanted to give special thanks to Matt Fausey to Chilkat Software, Inc. for pointing us in the right direction with this issue – while Matt has never used Dynamics NAV, he was able to point us to the Chilkat Mono offering which offered a pure C# implementation of the product (basically a wrapper) that then called the necessary native methods through P/Invoke – thanks again Matt for your help!

Related Posts

Recommended Reading:

Managing Your Business Through Uncertain Times Using Dynamics 365 Finance and Operations

  Dynamics 365 Finance and Operations (F&O) can help you make informed decisions on how to move your business forward. […]

Read the Article
5.13.22 Power Platform

Using Power BI Object Level Security

  The following article will demonstrate how to use Power BI Object Level Security to disable column data based on […]

Read the Article
5.12.22 Dynamics CRM

How to Use the Stoneridge Support Portal

Stoneridge Software’s support portal is an intuitive and useful function that makes it easy for you to access resources to […]

Read the Article
5.6.22 Dynamics GP

Dynamics GP Transaction Removal: Purchase Orders

  Are you having performance issues with Purchase Orders?  Do you find that there are old Purchase Orders on your […]

Read the Article
5.5.22 Dynamics GP

The Real Story about the Long-Term Future of Dynamics GP Support

I’ve seen a number of people put forward comment that Dynamics GP is going away and you have to get […]

Read the Article

New Features in Dynamics 365 Business Central 2022 Wave 1 Release – Financial Enhancements

The Dynamics 365 Businses Central 2022 Wave 1 Release has a lot of new and exciting features to help your […]

Read the Article
4.29.22 Dynamics GP

Dynamics GP Transaction Removals: Bank Reconciliation

  This is part 2 of a 3 part series on Dynamics GP Transaction Removals. These quick tips will hopefully […]

Read the Article
4.28.22 Dynamics GP

Uncommonly Used Features – Integrate Purchasing and Payables to Fixed Assets in Dynamics GP

Being able to integrate Purchasing and Payables to Fixed Assets in Dynamics GP will help you create visibility for your […]

Read the Article

New Features in the Dynamics 365 Business Central 2022 Wave 1 Release – Ease-of-Use Features

  There are many new features in the Dynamics 365 Business Central 2022 Wave 1 Release to get excited about! […]

Read the Article

Start the Conversation

It’s our mission to help clients win. We’d love to talk to you about the right business solutions to help you achieve your goals.

Subscribe To Our Blog

Sign up to get periodic updates on the latest posts.

Thank you for subscribing!