Error Loading .NET Assemblies in LabVIEW

Issue Details

• When I try to load a .NET assembly using the Constructor Node VI in LabVIEW, I receive one of the following error messages:

An error occurred trying to load the assembly.
The version of the assembly you requested was automatically promoted to a later version by the .NET runtime engine.

• When I upgraded the version of my .NET assembly my VI got a broken run arrow because the wire between my constructor node and subsequent property or invoke node was broken. 

Solution

This error may be caused for different reasons. This article will cover the most common causes and propose solutions for each one.
 

Security Restrictions

This issue could be related to security restrictions being placed on .NET assemblies. There are two ways to grant assemblies from remote sources full trust: using a LabVIEW configuration file or by allowing individual assemblies manually.

LabVIEW .NET Configuration File

Follow these steps to allow LabVIEW access to all .NET assemblies. Please note that this approach imposes a potential security risk.

1. Use a text editor to create a file that contains the following text: 

<?xml version ="1.0"?>
<configuration>
    <runtime>
        <loadFromRemoteSources enabled="true" />
    </runtime>
</configuration>

2. Save the file as LabVIEW.exe.config in the same directory of the LabVIEW.exe file. This directory is typically located in C:\Program Files (x86)\National Instruments\LabVIEW 20xx\.
3. You can also see Configuring a .NET Client Application - LabVIEW Help for more information on how to apply configuration files to a LabVIEW project, shared library, or stand-alone executable. Please note that such a reduced scope lowers the potential security risk by generally allowing remote assemblies to be loaded.

Granting Access Rights Manually

The following is only possible in Windows 7 and later. If LabVIEW fails when loading an assembly, Windows will add an option to unblock the assembly on the file's properties as shown in the picture below. Check Unblock and click OK to grant an assembly full trust.

Missing Dependencies

This problem may also occur if LabVIEW is not able to find dependent assemblies. Make sure all the assemblies and dependencies you are trying to add to the VI are located in the same project directory as the VI you are adding the assembly to. To check dependencies, you may review the manifest embedded within the assembly by using IL Disassembler (ILDASM.exe) that installs with Microsoft Visual Studio.

Using .NET Core

Another reason for getting this error may be that the .NET assembly was built using the .NET Core instead of the .NET Framework. LabVIEW does not support .NET Core assemblies due to the reason that LabVIEW uses the .NET Framework/CLR 4.0. LabVIEW has access to the class library assemblies associated with the .NET CLR 4.0 which installs with LabVIEW.
 

Additional Information

LabVIEW 2013 uses .NET 4.0 by default, while later versions of LabVIEW use more recent versions of the .NET framework. When loading an assembly targeted to any earlier versions of the .NET Framework, LabVIEW will automatically promote the assembly to the later version.

With .NET 4.0, a new security model was introduced. This new security model automatically grants full trust to locally available assemblies, but not to assemblies obtained from remote sources like the Internet, network locations, or via email. In case LabVIEW tries to access such an assembly's DLL file with missing trust and is thus denied access, LabVIEW will return an error. When using any virtualization solution like Parallels Desktop, VMWare Fusion, or Oracle VirtualBox to run Windows inside a virtual machine, the new security model treats the shared directories (e.g. folders that begin with /psf or \\vmware-host\) as remote sources, as these are accessed through a network link. You need to grant assemblies in these directories full trust as well.