This article describes relatively difficult and non-obvious issues that are likely to arise when creating COM class in Visual Studio and deploying it by professional MSI-authoring tools. It is assumed that the reader is already familiar with the classes in Visual Studio.
1. Create a class and compile into, say, mydll.dll.
2. Open Properties of the assembly, and check “Make assembly COM-visible”. There’s related checkbox under Build - “Register for COM interop”. That one is related to the local machine of the developer, it registers just-built dll. This may be handy later if Wise product is used to create the MSI - Wise needs COM object registered on the machine in order to extract its COM information. The registration can be later cleaned up from the developer’s machine by using action “Clean” from the menu “Build” - cleaning will unregister the dll.
3. Sign the assembly. Depending on where it's going to be used, you can generate new certificate, of use the one already trusted by the domain where the library will be used.
Why: because when this dll is deployed, .Net won’t allow it to be used by other applications unless it has strong name.
4. Open bin/release folder, and extract COM information from the mydll.dll, by running regasm /codebase /regfile:mydll.reg mydll.dll
. If you forgot #3 above, regasm will show an error to the same effect.
5. Open mydll.reg and visually inspect it. For instance, if mydll.dll was using webservice (such as UPS or Fedex ones), all public members of the webservices will be exposed by the COM object - which is probably not what we want. If so, delete them.
6. Create the MSI. Mydll.dll can be placed either in its own directory, or in GAC. If it’s placed in its own directory, then the above command regasm
does not need parameter /codebase
. /codebase creates an extra registry value in .reg file that will tell Framework where the actual dll is. Without it, Framework will be looking in GAC and in %path%, and won’t find it.
7. Import mydll.reg into the same component in the MSI as mydll.dll. Inspect visualy, and if the path of mydll.dll appears hardcoded from the developer’s machine, replace it by [#filekey]
, where filekey
is the key of mydll.dll in the table File
in the MSI.
8. The above is sufficient for runtime operation of the library. If the development with this library as a reference is in the plans as well, then in addition to the dll itself we also need to generate and deploy type library.
9. To generate the type library, run regasm /codebase /tlb:mydll.tlb mydll.dll
. This will create new file mydll.tlb.
10. Include mydll.tlb in the installation as new component, with extracting COM information. In the light of the latest recommendations, delete advertising information about Typelib if it was extracted (i.e. delete the contents of the table Typelib
in the MSI), but ensure that the equivalent entry is present in Registry table.
11. Visually verify that registry information for the typelib includes keys HELPDIR and win32.