- Referencing a COM Component in Visual Studio .NET
- Referencing a COM Component Using Only the .NET Framework SDK
- Example: A Spoken Hello, World Using the Microsoft Speech API
- The Type Library Importer
- Using COM Objects in ASP.NET Pages
- An Introduction to Interop Marshaling
- Common Interactions with COM Objects
- Using ActiveX Controls in .NET Applications
- Deploying a .NET Application That Uses COM
- Example: Using Microsoft Word to Check Spelling
- Conclusion
Deploying a .NET Application That Uses COM
Deploying a .NET application that uses COM components is not quite as simple as deploying a .NET application that doesn't. Besides satisfying the requirements of the .NET Framework, you must satisfy the requirements of COM. This means registering the COM component(s) in the Windows Registry on the user's machine, just as you would have if no managed code were involved. This is usually accomplished by running REGSVR32.EXE on each COM DLL. It might also be necessary to register type libraries, which adds additional registry entries for interfaces. If you're relying on a component being installed (such as the Microsoft Speech SDK), no additional work is necessary, except the supplied installation.
Unless you late bind to the COM components and only create COM types via ProgID or CLSID, you also need to deploy metadata for the COM components you use. This is no different from managed types because metadata is needed at compile time and at run time. It sometimes seems like more of a burden for COM types, however, because the metadata resides in an Interop Assembly separate from the file containing the implementation. These should be installed just like other assemblies, either in the Global Assembly Cache and/or in an application-specific directory.
You should avoid deploying Interop Assemblies for COM components you didn't author if Primary Interop Assemblies already exist. If you need to create Primary Interop Assemblies for your own COM components, see Chapter 15.