You are here: NI Home > Support > Product Reference > Manuals > LabVIEW 8.5 Help

You can use LabVIEW as a .NET client to access the objects, properties, methods, and events associated with .NET servers. You also can host .NET user interface controls (known as WinForms) on a VI's front panel. By default, LabVIEW automatically sets any .NET controls to run in the UI thread. While LabVIEW is not a .NET server, you can communicate to it remotely via the LabVIEW ActiveX server interface through .NET's support for COM objects. The .NET Framework allows you to access Windows services, such as the performance monitor, the event log and the file system. The next generation of the .NET Framework, WinFX, provides even more support for integrating Windows APIs, such as the Speech Recognition and Generation service. The .NET Framework also provides access to web protocols, such as SOAP, WSDL, and UDDI.

Note  Creating and communicating with .NET objects requires the .NET Framework 1.1 Service Pack 1 or later. National Instruments strongly recommends that you always put VIs that use .NET objects in a LabVIEW project and not leave them as stand-alone VIs.

.NET Environment

The following list provides a background of the various elements that make up the .NET environment. The purpose of this information is to help you understand .NET, but learning this information is not essential for you to use the .NET components in LabVIEW.

• Common Language Runtime (CLR)—A set of libraries responsible for run-time services, such as language integration, security enforcement, memory, garbage collection, process management, and thread management.

  To help .NET communicate with various programs, the CLR provides a data type system that spans programming languages and operating system boundaries. Developers then can view the system as a collection of data types and objects rather than as a collection of memory and threads. The CLR requires compilers and linkers to generate information in the CLR intermediate language (IL) metadata format. All .NET programming language compilers generate CLR IL code rather than the assembly code.

• Class Libraries—A set of classes that provides standard functionality, such as input and output, string manipulation, security management, network communications, thread management, text management, user interface design features, and so on. These classes provide the same functionality as the Win32/COM system. In the .NET framework, you can use classes created in one .NET language in another .NET language.
• Assemblies—A unit of deployment similar to a DLL, OCX, or executable for a component in COM. Assemblies are DLLs and executables you build using a .NET compiler. Assemblies can consist of a single file or multiple files. An assembly includes a manifest that contains information about the assembly name, version information, local information, publisher's security information, list of files that make up the assembly, list of dependent assemblies, resources, and exported data types. Refer to Using .NET Assemblies with LabVIEW for additional details.
• Global Assembly Cache (GAC)—A listing of the public assemblies available on the system. The GAC is analogous to the registry that COM uses.

.NET Functions and Nodes

Use the following LabVIEW VIs, functions, and nodes located on the .NET palette to access the objects, properties, and methods associated with .NET servers:

• Use the Constructor Node to select a constructor of a .NET class from an assembly and create an instance of that class on execution. When you place this node on the block diagram, LabVIEW displays the Select .NET Constructor dialog box.
• Use the Property Node to get (read) and set (write) the properties associated with a .NET class. Many .NET classes have an EnableEvents property. If you are not receiving events, you might need to set an EnableEvents property.
• Use the Invoke Node to invoke methods associated with a .NET class.
• Use the Close Reference function to close all references to .NET objects when you no longer need the connection.
• Use the Register Event Callback function to register and handle .NET events.
• Use the Unregister For Events function to unregister a .NET event.
• Use the To More Generic Class function to upcast a .NET reference to its base class.
• Use the To More Specific Class function to downcast a .NET reference to its derived class.
• Use the To .NET Object VI to convert a LabVIEW type to a .NET object.
• Use the .NET Object To Variant VI to convert a .NET object to a LabVIEW variant.
• Use the Static VI Reference function to create a strictly typed VI reference to a callback VI you create.

Creating .NET Objects

You can create .NET objects on the front panel or the block diagram. Use a Constructor Node to create a .NET object on the block diagram. Use a .NET container to create a .NET control on the front panel. You also can add .NET controls to the Controls palette for later use.

Note  You cannot switch between design mode and run mode for a .NET container as you can for an ActiveX container. The behavior of a .NET container is similar to that of an ActiveX container in design mode.

If you create a VI with .NET controls, consider using the user interface execution system. Generally, .NET controls must be accessed from the thread on which they were created (the user interface thread). By default, LabVIEW automatically sets any .NET controls to run in the UI thread. This can impact performance. If your VI with .NET controls seems to run slowly, try using the user interface execution system for that VI. Select File»VI Properties and select Execution from the pull-down menu to display the Execution Properties page. Then select same as caller from the Preferred Execution System list.

.NET Properties and Methods

.NET-enabled applications include objects that have exposed properties and methods that other applications can access. Objects can be visible to the users, such as buttons, windows, pictures, documents, and dialog boxes, or invisible to the user, such as application objects. You access an application by accessing an object associated with that application and setting a property or invoking a method of that object.

On the front panel or block diagram, right-click a .NET object and select Create»Property Node or Create»Invoke Node, and select a property or method from the shortcut menu to set a property or invoke a method for the object. You also can select .NET-specific properties or invoke .NET-specific methods for a .NET object. On the block diagram, right-click a .NET object and select Create»Property Node or Create»Invoke Node, and select a .NET-specific property or method from the shortcut menu.

Note  You cannot view and set .NET properties in a Property Browser as you can for ActiveX. You must set .NET properties using Property Nodes.

.NET Events

Events are the actions taken on an object, such as clicking a mouse, pressing a key, or receiving notifications about things such as running out of memory or tasks completing. Whenever these actions occur to the object, the object sends an event to alert the .NET container along with the event-specific data. The .NET object defines the events available for an object.

To use .NET events in an application, you must register for the event and handle the event when it occurs. .NET event registration is similar to dynamic event registration. However, the architecture of a .NET event VI is different than the architecture of an event-handling VI. The following components make up a typical .NET event VI:

• .NET object for which you want to generate an event.
• Register Event Callback function to specify and register for the type of event you want to generate. The Register Event Callback function is a growable node capable of handling multiple events, similar to the Register For Events function.
• Callback VI that contains the code you write to handle the event you specify.

When you wire a .NET object to the Register Event Callback function and specify the event you want to generate for that object, you are registering the .NET object for that event. After you register for the event, create a callback VI that contains the code you write to handle the event. Different events may have different event data formats so changing the event after you create a callback VI might break wires on the block diagram. Select the event before you create the callback VI.

You can handle events on .NET controls in a container. For example, you can place a calendar control in a .NET container and specify that you want to handle a DoubleClick event for the items displayed in the calendar.

Data Type Mapping

LabVIEW converts the data types of the .NET property, method, and constructor parameters into LabVIEW data types so LabVIEW can read and interpret the data. LabVIEW displays data types it cannot convert as .NET refnums. The following table lists the .NET data types and the converted LabVIEW data type.

.NET Types	LabVIEW Types
System.Int64, System.UInt64, System.Int32, System.UInt32, System.Int16, System.UInt16	, , , , ,
System.String
System.Boolean
System.Byte, System.Char, System.UByte
System.Single, System.Double, System.Decimal
System.Array	Displayed as an array of the corresponding type
Enumeration	Displayed as a ring control, constant, or indicator with an integer value of a corresponding type.
DateTime
Any other .NET object

Maintaining .NET Assemblies

LabVIEW can find .NET assemblies in the following places:

• Global Assembly Cache (GAC)—LabVIEW can access all assemblies in the GAC.
• Specified subdirectories—LabVIEW can search directories for assemblies that you use. If you use .NET objects in a saved project, LabVIEW searches the directory that contains the project and all subdirectories of that project. If you use .NET objects in a shared library or stand-alone application, LabVIEW searches the directory that contains the library or application and the data and bin subdirectories. If you use .NET objects in a location other than a saved project, shared library, or stand-alone application, save the assembly files in the GAC or use a relative path.
• Relative path—LabVIEW can access a relative path for assemblies that you use. Use relative paths only if you use .NET objects outside of a project.

After you create a VI that includes .NET components, you can build that VI into a shared library or stand-alone application. LabVIEW copies the associated private .NET assembly files to the data subdirectory in the same directory as the library or application.

You also can distribute .NET VIs to another location. If you distribute .NET VIs, libraries, or stand-alone applications, you either must move the associated private .NET assembly files to a subdirectory that LabVIEW can search, or you must save the files in the GAC. Make sure that the target computer has the .NET framework installed.

Configuring a .NET Client Application

.NET provides administrative capability to an application by using configuration files. A configuration file contains XML content and typically has a .config extension. To configure a LabVIEW .NET client application, you can provide a configuration file for a saved project, shared library, or stand-alone application. Name the configuration file the name of the project, library, or application with a .config extension, for example, MyApp.lvproj.config, MyApp.dll.config, or MyApp.exe.config. Save the configuration file in the directory that contains the project, library, or application. If you build a stand-alone application from a saved project with a configuration file, you must rename and save that configuration file in the directory that contains the application. For example, if you build a stand-alone application from foo.lvproj that has the configuration file foo.lvproj.config, rename the file foo.exe.config and save it in the directory that contains foo.exe, the stand-alone application. When working with .NET assemblies, you can use your .config file to store preconfiguration code before running the assembly or application. For example, you can use the .config file for any of the following tasks:

• loading assemblies
• choosing the CLR version
• setting up remote .NET access
• setting logging options
• setting security

Review the specific documentation for your .NET type to ensure you are using the .config file correctly.