If you reference a .NET object from the front panel or block diagram of a VI, ensure that LabVIEW can load the .NET assembly for that object. The Common Language Runtime (CLR) is responsible for locating .NET assemblies that you call. Refer to the Microsoft Developer Network (MSDN) Web site for more information about how the CLR locates assemblies. If the CLR cannot find the assembly, LabVIEW then searches for the assembly in the same manner it searches for missing VIs. LabVIEW searches for missing VIs in the directories you specify on the Paths page of the Options dialog box. If LabVIEW cannot find the .NET assembly for a .NET object referenced directly on the front panel or block diagram, LabVIEW generates a load-time error. If LabVIEW cannot load a dependent assembly needed during run time, LabVIEW generates a run-time error.
The CLR uses the directory of the running executable as the default search path when it loads private .NET assemblies. If you reference a .NET object from a VI that does not belong to a LabVIEW project, the CLR considers LabVIEW.exe to be the running executable. The CLR therefore searches for private assemblies in the directory in which the LabVIEW.exe file is located. If you reference a .NET object from a VI that does belong to a LabVIEW project, the CLR considers the project to be the running executable. The CLR therefore searches for private assemblies in the project directory. If you reference a .NET assembly from a VI and the assembly does not belong to the .NET Framework, National Instruments strongly recommends that you store the VI in a project to avoid having to place files in the directory in which the LabVIEW.exe file is located.
If you call a .NET assembly from a VI that does not belong to a project, you technically can save the assembly in the same directory as its calling VI. LabVIEW searches certain VI directories, including the calling VI directory, for assemblies that the CLR cannot load by default. However, calling assemblies stored in this location can result in name conflicts and other unexpected .NET behavior. Therefore, National Instruments does not recommend that you save assemblies in this location.
After LabVIEW loads an assembly into memory, the assembly stays in memory until you close the application instance that loaded the assembly. While an assembly is in memory, LabVIEW does not detect changes that you make to the assembly on disk. Therefore, before LabVIEW can access any changes to the assembly, you must update the assembly version in memory.
Microsoft Visual Studio .NET and other development tools provided in the .NET Framework SDK can assign strong names to an assembly. Assemblies with the same strong name are expected to be identical.
When you load a VI with a change in the path of a .NET assembly or with a change in the version number or culture string of a strong-named assembly, LabVIEW launches a warning dialog box informing you of the change. Once loaded, the VI includes an asterisk in its title bar and in the list of open VIs displayed in the Window menu. When you save the VI, the asterisk disappears until you make a new change.
When you load a VI with a change in the time stamp of a .NET assembly, LabVIEW does not launch a warning dialog box but does display an asterisk in the title bar of the VI.
|
Tip��Verify that LabVIEW is loading the correct version of your assembly by referring to the .NET Assemblies in Memory dialog box. |
Refer to the KnowledgeBase at ni.com for more information about how to select and load specific versions of .NET Assemblies.