Error Loading .NET Assemblies in LabVIEW

Updated Jul 20, 2020

Reported In


  • LabVIEW

Operating System

  • Windows


  • .NET Assemblies

Issue Details

When I try to load .NET assemblies 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.


  • This problem could be related to security restrictions being placed on assemblies.  There are two ways to grant assemblies from remote sources full trust: either by generally allowing LabVIEW to access these through a token in a .NET configuration file, or by allowing individual assemblies manually.


.NET configuration file

Follow these steps to allow LabVIEW access to all .NET assembly. 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"?>
        <loadFromRemoteSources enabled="true" />

  2. Save this file as LabVIEW.exe.config in the same directory as the file it was created for, e.g. you would save a LabVIEW.exe.config file in the same directory as the LabVIEW.exe file, which is typically located in C:\Program Files (x86)\National Instruments\LabVIEW 2018\. If you are adding this to a LabVIEW executable, save a LabVIEW.exe.config file in the same directory as [yourapplication].exe
  3. This action allows the computer to trust all assemblies loaded into LabVIEW. You can also see Configuring a .NET Client Application - LabVIEW 2017 Help for more information on how to apply configuration files to LabVIEW Project files, shared libraries, or stand-alone executables. 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. After LabVIEW has failed loading an assembly, Windows adds an option to unblock the assembly on the file's properties:
Check Unblock and click OK to grant an assembly full trust.
  • This problem could also be due to the dependent assemblies not being able to be found.  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.
  • Another reason could be that the .NET assembly was build as .NET Core instead of 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 by default. 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:  An error occurred trying to load the assembly.
Note: This error message may also occur when you attempt to load a 64-bit .NET dll into a 32-bit version of LabVIEW or vice-versa.

For information about loading .NET 2.0, 3.0, or 3.5 assemblies, please refer to Loading .NET 2.0, 3.0, and 3.5 Assemblies in LabVIEW - LabVIEW 2017 Help. Please note that when using .NET assemblies it is suggested to use a LabVIEW project rather than a stand-alone VI, .

Note: 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.