Configure .NET-Based Components for Registration-Free Activation

Question

I've been trying to get a registration-free .NET based COM DLL to work, but without success.

• In Visual Studio 2008 I added a new C# class library.
• I enabled the 'make assembly COM-visible' and 'register for COM interop' options.
• I added a public interface and class with some functions.
• I added a manifest dependency to my C++ client application: #pragma comment(linker,"/manifestdependency ...

But when I start my application I get 'the application has failed to start because the application configuration is incorrect'.

I've used Microsoft's mt tool to extract the manifest files of both the C++ client application and the C# COM DLL and the information in both is the same (the dependentAssembly in the C++ manifest file contains the same name and version as the assemblyIdentity in the COM manifest file).

I've also tried the approach described on http://msdn.microsoft.com/en-us/library/eew13bza.aspx but with similar results.

Similarly I tried to add a reference to my COM project in 'Framework and References' of my C++ client application. The information on that property page looked promising (it shows options like 'copy local', 'copy dependencies', etc and properties like the 'assemblyIdentity'), but Visual Studio neither copies the DLLs nor adds a dependency to the manifest file automatically.

Note that the 'registered variant' works fine.

Anyone have any ideas of what I'm doing wrong?

Update:

• When I create a simple C++ DLL and embed a manifest with the same name and version of my .NET COM DLL (same assemblyIdentity) my application starts up fine. So the problem lies with the manifest file of my .NET COM DLL.
• I can successfully extract the manifest from the DLL with mt -managedassemblyname:... and then embed the same manifest with mt -outputresource:..., but this also doesn't cause Windows to successfully resolve the dependency.

Answer 1

I found the steps needed to get registration-free .NET COM interop working myself :-)

• Run: mt -managedassemblyname:"myDll.dll" -out:"myDll.manifest"
• Clean manifest (see format at http://msdn.microsoft.com/en-us/library/eew13bza.aspx). Mainly I needed to remove all tags except for assemblyIdentity, clrClass and file (and specifically remove the runtime, mvid and dependency tags).
• Run mt -outputresource:"myDll.dll" -manifest "myDll.manifest". Basically this adds the modified manifest as a resource to the DLL. Note that this is apparently not the same manifest (location)! If I reextract the manifest with the managedassemblyname option I still get the 'old' manifest. If I extract it with the inputresource option I get the new one.

I pretty much found this all thanks to Windows Vista. Unlike my Windows XP it contains a tool called sxstrace that gives rather detailed information about the problems with side-by-side execution.