 | Supporting .NET Client Applications |
IVI-COM drivers provide seamless support for .NET applications through the use of special "wrapper" DLLs known as interop assemblies. These interop assemblies present a .NET interface to client applications built in languages such as C# and VB.NET. From the perspective of the .NET client, the experience is very much like using a native .NET component. Under the covers, the interop assembly simply delegates to the underlying IVI-COM driver. Nimbus automatically creates an interop assembly for every IVI driver and integrates it into the installer. The interop assembly name has the following form:
<driverVendor>.<driverName>.Interop.dll
This interop assembly is created as part of the driver build sequence and complies with the IVI interop assembly requirements laid out in IVI-3.14: Primary Interop Assembly Specification. The .NET Page of the Driver Settings Editor can be used to control the interop assembly name. In addition, two other critical aspects of .NET interoperability must be considered by the driver developer -- applying a digital signature to the interop assembly and versioning the interop assembly. This topic discusses digital signatures while the topic Understanding .NET Versioning explains how driver version numbers must be managed for .NET.
Interop Assemblies and Digital SignaturesAll .NET assemblies can be signed with a digital signature by using a command line tool known as the strong name utility (sn.exe).
There are three main reasons for signing a .NET assembly:
The digital signature allows clients to associate the assembly with a specific software publisher. This assures the end user that the assembly they have really came from the source they expect.
Signing an assembly provides a security assurance to the client application that the assembly has not been tampered with or altered since it was built by the person performing the signing.
Signing an assembly allows the assembly to be deployed in a special shared location on the client machine known as the global assembly cache (GAC). Deploying an assembly in the GAC ensures that .NET client applications will be able to locate and load the assembly at runtime.
For the reasons outlined above, the IVI Foundation requires that IVI-COM driver interop assemblies be signed with a digital signature. See IVI-3.14: Primary Interop Assembly Specification for details. The sections that follow provide basic information on how digital signatures can be applied to an IVI-COM driver.
Basics of Assembly SigningTo sign an interop assembly, you must have a public-private key pair. This public-private key pair is supplied to the strong name utility (sn.exe) to produce the digitally signed interop assembly. Public-private key pairs are extremely sensitive pieces of information. They represent the identity of your company as a software publisher, and, if compromised, could allow malicious users to impersonate your software. Thus, public-private key pairs must be securely stored.
 Caution |
|---|
Never store a public-private key pair on computer hard drive. A variety of simple, inexpensive devices are available for safely controlling access to the public-private key pair. |
Obtaining a Public-Private Key Pair
Most organizations developing IVI-COM drivers are likely to have already dealt with the issue of assembly signing for other .NET products they may have produced. Thus, it is important for the driver developer to check within their own company to determine if a public-private key pair has already been established for the company or organization.
| Caution |
|---|
Because the public-private key pair represents the digital identity of the company or organization, you should never simply create a new key pair just for the purpose of shipping a single IVI-COM driver. If the IVI-COM driver is, in fact, the first project that requires a public-private key pair, then it is highly recommended that the organization take the appropriate steps to create a standard, secure public-private key pair. |
Delay Signing
Since the public-private key pair is a sensitive piece of information and must be maintained in a secure location, driver developers will (hopefully) not have direct access to the key pair from their development machine. Yet, it is the driver developer who must apply the digital signature to the interop assembly when compiling the IVI-COM driver. To deal with this inherent dichotomy, the .NET Framework supports a feature called delay signing.
Delay signing allows a developer to create an interop assembly using only the public key portion of the public-private key pair. Only the private key portion of the key pair is sensitive, so it is perfectly safe to distribute the public key portion to driver developers.
The strong name utility (sn.exe) is used to extract the public key. From a Visual Studio command prompt, the trusted individual maintaining the secure public-private key pair would need to execute the following command:
sn -p keypair.snk public.snk
The above command will extract the public key from the key pair stored in the file keypair.snk and place it in a file called public.snk. The public.snk file is then distributed to the driver developers and other individuals needing to produce .NET components.
With the public key in hand, the driver developer instructs Nimbus to use that public key when building the IVI-COM driver interop assembly. This is done via the .NET Page of the Driver Settings Editor. Since, by definition, the delay-signed interop assembly does not contain a digital signature, it cannot be deployed in the GAC, nor can it be used in .NET applications that expect a full digital signature. Thus, before the driver can be shipped, it must be re-signed using the strong-name utility.
To re-sign an interop assembly, the trusted individual managing the public-private key pair would execute the following command from a Visual Studio command prompt:
sn -R MyCompany.MyDriver.Interop.dll keypair.snk
The above command will apply a full digital signature using keypair.snk to the IVI-COM driver interop assembly MyCompany.MyDriver.Interop.dll. (Note the somewhat verbose format for the interop assembly name follows the IVI-COM interop assembly naming convention presented in IVI-3.14: Primary Interop Assembly Specification).
| Caution |
|---|
You must never ship an IVI-COM driver interop assembly that has been delay-signed. The driver installer will fail to install the interop assembly in the GAC, and the driver will not be accessible from .NET client applications. |
Working with a Delay Signed Assembly
The re-signing procedure described above is typically only done just before an IVI-COM driver is ready to ship. During development, however, it is important to be able to use the interop assembly, particularly for the purposes of unit testing, since NUnit is based on .NET. For a delay-signed interop assembly to work, you must take an explicit step to instruct the .NET Framework not to try to validate the signature on the interop assembly, since it has been delay signed. If you do not perform this step, the delay-signed interop assembly will not deploy into the GAC, nor will it be usable from .NET client applications. This process is called verification skipping.
To register a driver interop assembly for verification skipping, execute the following command from a Visual Studio command prompt. Note that this command requires administrator privileges.
sn -Vr MyCompany.MyDriver.Interop.dll
The above command instructs the .NET Framework to skip verification of the interop assembly, allowing it to be used while it is delay-signed. Note that the command does not modify the interop assembly itself in any way, and the verification skipping only applies to the local machine. Thus, if the interop assembly is placed on a different machine, then it must again be registered for verification skipping by an administrator user on that machine. You can remove the verification skipping registration by executing the following command:
sn -Vu MyCompany.MyDriver.Interop
After executing the above command, the .NET Framework will once again go back to its normal mode of operation when loading the interop assembly, and attempt to verify the digital signature. If the assembly is still delay-signed, then it will not be usable or deployable in the GAC after executing the sn -Vu command.
See Also