This content is not available in your preferred language.

The content is shown in another available language. Your browser may include features that can help translate the text.

Error Loading .NET Assemblies in LabVIEW

Updated Jan 31, 2024

Reported In

Software

  • LabVIEW

Driver

  • IVI.NET Adapters

Programming Language

  • C# .NET
  • Visual Basic .NET

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.
System.BadImageFormatException: Could not load file or assembly <Assembly Name> or one of its dependencies. This assembly is built by a runtime newer than the currently loaded runtime and cannot be loaded.  
image.png
  • 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>
  1. 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\.
  2. You can also see Configuring a .NET Client Application 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.
 

Using .NET 2.0, 3.0, and 3.5 Assemblies in LabVIEW

If you are using a third-party .NET assembly please check the documentation to see what version of the .NET Framework is being used by the DLL. If you are using LabVIEW 2013 or later it is recommended that you use a version of the DLL that uses the .NET Framework 4.0 or later. You can force LabVIEW to load .NET assemblies that are targeted to the CLR 2.0, however, assemblies that target older versions of the CLR might behave unexpectedly. Follow the steps in the help documentation to load these types of assemblies: Loading .NET 2.0, 3.0, and 3.5 Assemblies in LabVIEW.


Using .NET 4.0 in old versions of LabVIEW 

Old versions of LabVIEW (2012 or below) use CLR 2.0, which let them load assemblies that are built-in .NET 2.0, 3.0, and 3.5, if your assembly was developed in .NET 4.0 or later, you will need to edit/create the configuration file to load .NET mixed-mode assemblies, the same way that was detailed in the Loading .NET 2.0, 3.0, and 3.5 Assemblies in LabVIEW.article from the last section. Even though the article is targeted to enable mixed-mode for loading old .NET assemblies in new versions of LabVIEW, it works the same way to make new versions of .NET assemblies load in old versions of LabVIEW
 

Incorrect Bitness

This may also occur when you attempt to load a 64-bit .NET DLL into a 32-bit version of LabVIEW or vice-versa.
 

Missing IVI .NET Adapters package from the NI IVI Compliance Package driver

If your assembly is built using IVI drivers as a component you may not have the .NET Adapter package from the IVI Compliance Package driver installed. This package was added to the NI IVI Compliance Package 19.0 driver and subsequent versions.

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.