.NET Interop mscorlib.dll version best practice?

wakestar

Hi there

When working with .NET Interop I always get a bit confused when it comes to selecting the right assembly.

For instance we need the File class which resides in the System.IO namespace in mscorlib.dll.

Depending on the environment you'll find more than one version of mscorlib.dll on your system.
So you create your DotNet variable ... drilldown on subtype ... lookup on assembly... and then you'll get this insane long list of assemblies on your system.
After a couple of minutes you might find the following verisons of mscorlib.dll:

Version 2.0.0.0.0 x86
Version 2.0.0.0.0 x64
Version 4.0.0.0.0 x86
Version 4.0.0.0.0 x64

In this case you don't even have to do the lookup... you can directly type 'mscorlib' in the assembly field and It will somehow automagically pick a version for you.

The image shows the exported code of a nav object which references the various mscorlib.dll versions.
The first one is the magic - version ... I have NO CLUE how NAV or the CLR handles this correctly or which version is actually loaded.

The question is: what is best practice?
- Using the older (v2) version or the newer (v4) version?
- Using x86 or x64? (looks like it doesn't matter since the informations in the text file are identical)

Anyone from Microsoft reading here maybe??

TList

Excellent question - let me see if I can answer it.

NAV uses .NET standard mechanisms for loading the types so you should not need to worry about framework assemblies as they are handled by the framework and will redirected appropriately regardless of the version and bitness you specify.
However, I recommend using framework version equal to or below to the version NAV uses (ex. NAV 2009 => .NET 2, NAV 2013 => .NET 4) as it helps finding the right method signatures in the NAV type picker.

For you custom assemblies, bitness might be a bit tricky but in the end only relevant on the client.
The NAV design time client (CSIDE) is a 32-bit client so it cannot load 64-bit .NET components. Trying to do so will cause compilation errors, unless you have an both 32 and 64-bit on the box (or AnyCPU).
The NAV Windows Client (RTC) is also a 32-bit client so trying to run a 64-bit .NET component here will result in runtime errors, again unless you have an both 32 and 64-bit on the box (or AnyCPU).
The NAV Service (NST) is a 64-bit service and it can load both 32-bit and 64-bit components but will prefer loading the 64-bit component first. The assemblies marked as AnyCPU will also be loaded as 64-bit on the service.

Personally I recommend compiling as AnyCPU and "only" think about bitness when it is required by an external component and even here try to get as much as possible into a "bit-agnostic" assemblies.

wakestar

Thanks a lot for the explanation!

Here are my two follow-up questions (sorry )

- How does the "RunOnClient" property affect the .NET loading behaviour in the C/Side Client?
(Is the .NET Type actually loaded where it should according to the RunOnClient Property when I select the .NET Type from the Assembly List?)

- Does compiling the NAV Object have the same effect? (the C/Side Client loads the .NET Types the same way as if you pick the .NET Type from the Assembly List)