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.
- Use a text editor to create a file that contains the following text:
<?xml version ="1.0"?>
<configuration>
<runtime>
<loadFromRemoteSources enabled="true" />
</runtime>
</configuration>
- 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\.
- 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.