Characteristics of LabVIEW-Built .NET Interop Assemblies

Calling a .NET Interop Assembly from Another Program

After you build a .NET interop assembly, you can call the assembly from other programs that support .NET. However, ensure that the computer on which the other program runs meets the following requirements and recommendations:

• The LabVIEW Run-Time Engine must be installed on any computer on which users run the .NET interop assembly. You can distribute the LabVIEW Run-Time Engine with the .NET interop assembly. (Windows) You also can include the LabVIEW Run-Time Engine in an installer.
• National Instruments recommends that the target computer for the .NET interop assembly have the same or later version of the .NET Framework installed as the version that LabVIEW used to build the application.
• To call the .NET interop assembly outside of the LabVIEW development environment, you must reference NationalInstruments.LabVIEW.Interop.dll in the Microsoft Visual Studio project. The LabVIEW Run-Time Engine automatically installs this DLL to the National Instruments\Shared\LabVIEW Run-Time directory. Optionally, you can manually install NationalInstruments.LabVIEW.Interop.dll to the Global Assembly Cache (GAC). If you want to install this DLL to the GAC, you must sign the .NET assembly with a strong name key file.
• When you create a debuggable .NET interop assembly, LabVIEW places a configuration (ini) file in the same directory as the assembly. If you want to debug the assembly in other programs, you must distribute the .ini file with the assembly.

LabVIEW Data Types in .NET Interop Assemblies

When you build a .NET interop assembly, LabVIEW directly translates simple data types such as numerics, booleans, strings, and arrays of simple data types to the corresponding .NET data type. However, LabVIEW-specific data types, such as clusters, waveforms, complex numbers, refnums, and LabVIEW classes, require LabVIEW to define new .NET data types in the generated assembly.

One way to determine how LabVIEW converts its own data types to .NET data types is to build the .NET interop assembly and then view the manifest of the assembly in a .NET programming environment such as Microsoft Visual Studio. You can also use the MSIL Disassembler tool available on the Microsoft Developer Network (MSDN) to view the generated assembly. However, the following sections explain some basic details about how LabVIEW converts clusters, enumeration type controls, and LabVIEW classes to .NET data types.

Clusters and Enumerations

LabVIEW converts clusters and enumerations to .NET structures whose elements correspond to the elements of the cluster or enumeration. LabVIEW uses the following rules to name the .NET structure that corresponds to a cluster or enumeration:

• Clusters and enumerations defined as type definitions or strict type definitions—LabVIEW uses the label of the type definition or strict type definition as the name of the .NET structure
• All other clusters and enumerations—LabVIEW names the .NET structure LVCluster_# or LVEnum_#

LabVIEW Classes

You can export the member VIs of a LabVIEW class. In LabVIEW, these VIs require the owning LabVIEW class as an input. Therefore, when you export these VIs to a .NET interop assembly, LabVIEW must create an equivalent .NET class definition in the assembly. The .NET class definition contains a static method for each member VI. Each of these static methods requires an instance of the newly defined .NET class as a parameter. LabVIEW does not export the private data of the owning LabVIEW class.

LabVIEW also exports the inheritance structure of LabVIEW classes whose method VIs you export. The generated .NET classes have the same inheritance structure.

LabVIEW Errors

When LabVIEW generates a .NET method for a VI, LabVIEW does not export the error in and error out clusters as parameters of the new method. Instead, the new method throws a .NET exception if an error occurs while the method is executing. This exception contains the same information as the error cluster.