Accessing Unmanaged DLL Functions From .NET Languages
While there are several ways of accessing C/C++ DLL functions in .NET, there's one standard way of getting access to such unmanaged functionality in C# and two ways in Visual Basic .NET. VB.NET was meant to be an upgrade to Visual Basic 6, which means Microsoft had to provide an upgrade path for the VB 6 C DLL interoperation mechanism—the Declare keyword. VB .NET has this keyword as well as the .NET attribute method of accessing C DLLs. Examples 1(a) and 1(b) are two equivalent declarations in VB.NET.
The Declare statement is more limited than the DllImportAttribute .NET attribute. For that reason and because the Declare keyword is not available in C#, the DllImportAttribute is preferable when source code that interoperates with both C# and VB .NET must be written.
The DllImportAttribute instructs .NET to use an unmanaged function to service a call to the method that the attribute is associated with. The attribute describes what file the unmanaged method is located in, the location in the file of the function's entry point, and any other information necessary to successfully build a call stack and pass parameters to the method.
Previous software reuse architectures, such as COM, focused on protecting programmers from themselves. COM had the concept of threading apartments—in theory, code could be made thread-safe simply by registering it as thread safe. In reality, apartments often created more problems than they solved. .NET did not follow this path, and calling unmanaged code from .NET does not cause thread switching. The thread context of the .NET program is passed directly into the unmanaged code, with the .NET infrastructure simply building the proper C or Pascal method call stack on top of the stack. Similarly, callbacks from unmanaged code are not marshaled across threads, meaning they may come back on a different thread than the one being used by the .NET application. This can cause runtime errors if the client application accesses methods that have a thread affinity such as many of the operations on GUI objects.
The parameters to the .NET method decorated with the DllImportAttribute attribute are used to determine what parameters to pass on or retrieve from the call stack. Each .NET value type such as integers and other built-in types such as .NET array types have standard marshaling behavior that are equivalent to common C/C++ data types. Using the ref or out keywords with the method's parameters will cause them to be marshaled by reference, passing the memory address rather than the value for the variable. Some .NET value types, such as integers, floating-point numbers, or single-dimensional arrays of those types, are even blittable, meaning they have the same memory layout in managed and unmanaged code and .NET does not need to do any time-consuming transformations or marshaling on them when calling unmanaged code.
.NET strings, by default, are passed by value, and attempts to modify such strings by the unmanaged code results in undefined behavior. The StringBuilder class has a useful marshaling behavior: It marshals as an array of C characters that is modifiable, the size of the array equaling the StringBuilder instance's Capacity property. Microsoft meant for StringBuilder objects to be used when unmanaged functions expect a preallocated character buffer parameter to be filled-in with string or character data by the unmanaged code.
While most primitive types have equivalents in .NET, some of these .NET equivalents are not supported by all .NET languages and are, therefore, not recommended. C# is one of the languages with the broadest compatibility with various primitive data types; and VB.NET is an example of a language with more restricted support for primitive types. Primitive types in .NET that are compatible with the widest set of .NET languages are said to be Common Language Specification (CLS) compliant. The biggest set of nonCLS-compliant primitive types are the unsigned integral types such as the System.Uint16 unsigned 16-bit integer. To support the broadest set of languages, Agilent made the VISA-C in .NET header files use signed integer types when the VISA-C function expects or returns unsigned integer types.
There is no need to provide an implementation for the method in the source code of C#, VB.NET, and the like; just provide an empty function and the .NET runtime will call the referenced unmanaged function. Such methods are typically declared static in C# or Shared in VB.NET because their behavior does not depend on any of the instance variables of the class in which they are defined.
—D.G.
