Ensuring Proper COM Registration (IVI-COM only)
One of the main tasks performed by an IVI driver installer is registration of various bits of COM infrastructure. Specifically, every class, enum, and interface in the driver must have an entry in the registry of the target machine. The COM runtime relies upon all of these entries to be complete and correct, else the driver will not operate properly.
There are two basic ways to perform COM registration for an IVI driver -- using the driver installer and using COM self-registration.
COM self-registration relies upon a pair of special functions present in all COM components -- including all IVI-COM drivers. These functions are DllRegisterServer and DllUnregisterServer and they contain the code necessary to run special registration scripts that add (or remove) the appropriate registry entries from the target machine. COM self-registration is performed by running the regsvr32.exe command-line utility and passing in the name of the driver DLL. This regsvr32.exe utility simply invokes the DllRegisterServer function. Passing in the /u flag to regsvr32.exe invokes the DllUnregisterServer to remove the driver's COM registration entries.
Though COM self-registration can be convenient, it is frought with problems that make it unsuitable for most general driver deployment scenarios. Not least amongst these disadvantages are its inability to perform reliable rollbacks and its lack of support for per-user registration. Consequently, IVI drivers should never rely upon COM self-registration for end-user deployment scenarios. Rather, the driver installer is constructed to explicitly register each COM enum, interface, and class using MSI infrastructure.
Never modify an IVI driver installer to use COM self-registration.
Although the previous section emphasized the importance of avoiding COM self-registration for driver deployment, it does prove to be useful for testing an IVI driver on a Nimbus developer machine. Each time the driver project is compiled, the regsvr32.exe command is run to perform the required COM registration of the driver. This enables the driver developer to immediately run unit tests or other test applications, without having to build and run the driver installer.
Running the driver installer in order to perform testing is not only extraordinarily inconvenient, it is also a VERY dangerous practice. This is because a single set of COM registry entries (those associated with the driver) are being manipulated by two different mechanisms that know nothing about one another -- COM self-registration and the Windows Installer infrastructure. If both of these mechanisms are used on the same machine, the registry could become corrupt and inexplicable errors are likely to occur. Since the COM self-registration is built into the driver compilation process and is, for all intents and purposes, required on the developer machine, it is imperative that the driver installer NEVER be run on a machine on which the same driver has been compiled. The driver installer must be tested on a separate machine. This rule is so important that it bears repeating.
NEVER run a driver installer on a Nimbus developer machine that has been used to compile that same driver. The registry entries associated with the driver could become corrupt. IVI driver installers MUST always be tested on a dedicated test machine -- not on the same machine on which they were developed.
COM objects are typically registered in the machine-wide registry hive. Since per-machine settings present greater security concerns, this typically meant that registering a COM object required administrator privileges.
Beginning with Visual Studio 2008, an additional option is available for COM registration -- per-user COM registration. Indeed, for Visual Studio 2008 it is important to note that per-user COM registration is the default mode. As the name implies, per-user COM registration places the COM object's registry entries in the per-user registry hive. This means that administrator privileges are not required when using per-user COM registration.
Since per-user COM objects do not require administrator privileges to register, the operating system uses different rules to load them. These rules are intended to keep a per-user COM object which may have been installed by a relatively low privileged user from getting loaded into an application that is running with high privileges. Consequently, it is possible that per-user COM objects are not visible to certain applications running on a machine. The table below summarizes the loading policy. Note that the table shows the loading policies as of Windows Vista SP1.
Per-User COM Visible
Download a complete CHM version of this documentation here.