Error Loading .NET Assemblies in LabVIEW

Updated Sep 9, 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.

A. 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\ for 32-bits versions and  C:\Program Files (x86)\National Instruments\LabVIEW 20xx\ for 64-bit versions.
  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.

B. 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 in earlier versions than LabVIEW 2024 Q3

Another possible cause of this error could be that the .NET assembly was built with .NET Core rather than .NET Framework. LabVIEW 2024 Q3 introduced limited support for .NET Core (8.0) assemblies, while earlier versions do not support .NET Core assemblies because they are based on .NET Framework/CLR 4.0. Older LabVIEW versions only integrate with class library assemblies associated with .NET CLR 4.0.

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 lets 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.

Using Assembly Downloaded from Visual Studio NuGet Targeted .NET 4.8.1 and newer

If you are using assembly downloaded from NuGet from a .NET project targeted .NET Framework 4.8.1, try to download the same NuGet package that is targeted .NET Framework 4.6.2. Since LabVIEW is using .NET Framework 4.6.2, calling assembly using the same .NET Framework version can reduce potential incompatibility issue.

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.