Dynamics NAV – Not All Assemblies are Created Equally

by | Updated August 15, 2016 | Dynamics NAV, Set Up

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

0 Comments

Submit a Comment

Your email address will not be published. Required fields are marked *

Upcoming Events

september

02sep10:00 am10:30 amThe Modern Manufacturer - Cycle Count Management

02sep12:00 pm12:30 pmBest Practices for Work Order Planning and Routing for Field Service Companies

09sep10:00 am11:00 amWhat is Levridge? An Overview of the Ultimate Ag Solution

09sep12:00 pm12:30 pmOverview of Microsoft Promotion for NAV and GP Clients

10sep11:00 am12:00 pmConfab with Stoneridge - Livestream - Field Service Comparisons

16sep10:00 am10:30 amThe Modern Manufacturer - Product Lifecycle Management

16sep12:00 pm12:30 pmHow to Upgrade to Dynamics 365 Finance and Operations: Examining Custom Code and ISV Implications

16sep2:00 pm2:30 pmScheduling and Dispatching for the Modern Field Service Company

23sep12:00 pm1:00 pmDynamics 365 Business Central Wave 2 Release Preview - An Overview of the Most Exciting New Features Coming in October

24sep11:00 am12:00 pmConfab with Stoneridge - Livestream - The Modern Workplace: Teams, Sharepoint, Outlook, Office, and AI Integration

30sep10:00 am10:30 amThe Modern Manufacturer - Return Management

30sep12:00 pm12:30 pmEmpowering Your Field Service Technicians with a Mobile Solution

october

07oct12:00 pm1:00 pmThe Three Paths to Business Central from Dynamics GP

08oct11:00 am12:00 pmConfab with Stoneridge - Livestream - The Vision and Strategy of Microsoft Business Systems

14oct10:00 am10:30 amThe Modern Manufacturer - Complex Cost Modeling

14oct12:00 pm12:30 pmGenerating Custom Inspection or Process Forms

19octAll Day22Stoneridge Connect Fall 2020

22oct11:00 am12:00 pmConfab with Stoneridge - Livestream - Stoneridge Connect Recap

28oct10:00 am10:30 amThe Modern Manufacturer - Engineering Change Orders

About Stoneridge
Stoneridge Software is a unique Microsoft Gold Partner, with emphasis on partner. With specialties in Microsoft Dynamics 365, Microsoft Dynamics AX, Microsoft Dynamics NAV, Microsoft Dynamics GP and Microsoft Dynamics CRM, we focus on attracting the most knowledgeable experts in the field to our team, and prioritize delivering stellar solutions with maximum impact for your business. At Stoneridge, we are deeply committed to your results. Each engagement is met with a dedicated team, ready to provide thorough, tailored, and expert service. Based in Minnesota, we intentionally “step into your shoes,” wherever you are. We focus on what you care about, and develop trusting, long-term relationships with our clients.

Subscribe To Our Blog

Sign up to get periodic updates on the latest posts.

Thank you for subscribing!

X