My project uses several dll files with activex controls.
Now I am making a deployment project (windows installer).
I need to register dlls via windows installer using regsvr32. How should I do it ? And can I detect if regsvr32 failed or not ?
My project uses several dll files with activex controls.
Now I am making a deployment project (windows installer).
I need to register dlls via windows installer using regsvr32. How should I do it ? And can I detect if regsvr32 failed or not ?
I assume when you say you're creating a deployment project, you're talking about the nasty piece of work that's available in Visual Studio?
If so, for each DLL, you can look at their properties, and set the "Register" property to COM.
If you're using some other deployment technology (e.g. Wix, InstallShield, etc), then the answer will vary, but most of these have a simple setting to say "this is an COM dll that needs to be registered", rather than you having to kick off regsvr32.
As to detecting failure - by using the built in facilities, the COM registration takes place during the normal install process, and failures cause the install to rollback - there's no need to check this yourself; in much the same way that you don't have to check that your files made it to the install location, and don't have to worry that the disk was full.
The best way to use regsvr32
to register a COM interface during an install is, don't. (grin)
Calling regsvr32
and other forms of "self-registration" during Windows Installer-based installs is bad practice. COM interfaces are often shared between multiple products. If package A registers COM interface IFoo
, then package B (re)registers the same interface, then if either package is uninstalled and unregisters IFoo
it breaks the remaining package.
The preferred method is to extract the COM interface information and build it into Registry table entries in the .msi
package. MSI recognizes matched COM Registry entries and manages a reference count of them rather than duplicating them. The 2nd..Nth entry just bumps the reference count, each uninstall merely decrements it, until the last uninstall decrements the ref-count to zero and Registry entries are actually removed.
In WiX, the heat tool is used to "harvest" COM interfaces (among other data) into WiX source fragments containing the necessary Registry entries. Installshield has a "COM extract at build" flag that does the same thing for MSI and Installscript-MSI projects. Other Windows Installer toolsets have similar capabilities.
Note: Windows Installer(MSI) is the underlying installation-management API that is part of Windows itself. You need additional tools to generate .msi
packages that use this API.
Windows Installer XML (WiX) is an XML schema for describing MSI-based install packages, along with tools to generate the actual .msi
package from documents in that schema. Installshield is another tool that can generate .msi
packages.
Those are the two that I have used. There are other tools such as InstallAware and Advanced Installer. I cannot speak to their capabilities, having never used them myself. Visual Studio also has a plug-in to generate install packages, but in my experience it scales poorly to industrial-strength products.
You should investigate WiX It is an open source project by MS that creates windows installers (.msi) There is a tool with that called heat that generates code on different inputs, one of which is dll registers etc. The installer framework will take care of whether proper registration has occurred