Using ActiveX within .NET, Versioning, manifests and issues

I decided to start this off with a posting on how ActiveX objects get used within .NET applications (be it a Windows service or otherwise -- I'll talk about ASP.NET separately). I'm going to be concerned only with VS2005 and .NET 2.0 but I won't have code snippets here.

I will also be talking a little bit about Side-by-Side (SxS) running of components.

One sentence sums it up: It's as seamless as possible. One thing it can end up doing is to expose bugs in your COM component that were not seen before. e.g., any threads hosting the component run as STA, and that combined with the Hyperthreading support in Intel processors or multi-processor machines can expose condition in the code that should ideally be surrounded by mutexes.

When one writes COM code, one does not care about the critical section as much as you would need to care for starting now...
---
When you include an ActiveX component as part of your Project, e.g. drop in on a WinForm, VS2005 will automatically create wrapper functions for you that will hide the ICoInitialize and other ICo* COM interfaces from you. You can also create a AxHost class manually. Your instances will then be "objects" of this AxHost class.

The most crucial part of doing this for Enterprise and professional applications is the versioning aspect. We know that the Ax .ocx components have to be registered on the machine in order for them to be referenced correctly. Fortunately, VS provides a way around that with the support for .manifests.

Manifests are essentially "redirectors" that allow the .NET runtime to use a local/different copy of the component than the one actually registered on the machine. This is dynamically decided. Manifests are always associated with .exe files only. You will have at least and at most one manifest per .exe.

So, your foo.exe will have a corresponding foo.exe.manifest. It's a XML file that stores the GUID references that should be used and the pointer to the component that needs to be loaded up.

Issues:
1.) Developer machines: Note that although manifests don;t require any component registration, the correct component has to be registered on the machine where the development is happening. It is also a requirement for machines that do automated compilation. It's not required only for the actual build copy running just the .exe and supporting DLLs and other files.
2.) Versioning: This is again a problem with testing on developer machines. If the GUID for component changes, the developer would need to register the correct version and use that instead. This would need to happen for every version that breaks compatibility.
3.) ASP .NET: This is by far the most crucial. .NET 2.0 actually removed support for manifests. Note that ASP .NET processes don't run as separate exe's. They are all hosted with the primary IIS application aspnet_wp.exe. In my trial, I was not able to associate a manifest with the exe and get it working at the same time -- a pity that the support was removed.

Note: Manifests are inherently supported by WinXP and Win2003 server and not by Win2000 server and previous editions of Workstation OSes. This is the SxS support I was talking about -- google and you will find tons of information on them.

Windows services and applications behave the same when it comes to manifests.
---
One way to overcome all these issues would be to provide a clear demarkation using the MVC pattern for COM components. It's always good to clearly demarcate the GUI part into an OCX and have the "backend" functionality into a DLL. In this way "server" software, like ASP .NET pages, can use the DLL to perform any manipulation needed and does not depend on the requirement for a component registration or manifests. From this, it is clearly obvious (if it was not before) that registration is needed for ocx'es only.
---
Comments are welcome. Clarification will certainly be provided if solicited.