Can registration of free COM be applied to a DLL?

Question

At the moment, I have something similar for installing COM without registering:

• a.exe (depends on b.dll ; does not depend directly on c.dll )
• a.exe.manifest (announces registration without registration for c.dll )
• b.dll (depends on c.dll . For example, the created .NET TMBIMP COM shell)
• c.dll (some COM DLL implementation)
• c.dll.manifest (manifest declaration without registering for c.dll )

Is it possible to change this scheme so that the manifest located on a.exe is instead placed on b.dll ? I would like other programs to be able to reference b.dll without adding additional manifests if necessary.

( a.exe.manifest has the following content:

  <file name="msdia110.dll"> <comClass description="Debug Information Accessor" clsid="{761D3BCD-1304-41D5-94E8-EAC54E4AC172}" threadingModel = "Both"/> </file> 

)

and c.dll.manifest were generated using the mt.exe manifest mt.exe . (and too long to include here)

Answer 1

My experience is that it does not work, or rather you need to go into the activation context API to actually use the manifest in the DLL: see this question: Move the manifest file to dll?

My attitude to this, although perhaps not entirely accurate, is this:

• Registry-based COM is "global" to the user

• Regfree manifest COM is global for each process and must be managed by an executable.

Only the executable manifest is always "in scope", if you have DLL files with parallel COM manifests, you force it to be explicitly loaded using the Activation Context API, and the problem is that it can only work when you are exactly You know when it’s necessary, and control the call path to the places in the DLL where necessary.

Because, as I understand it, what you really do when you have "a.exe.manifest (announces COM registration for c.dll)" is that you change the initial / global activation context for this process. This (looks like) only works for an executable manifest. Any manifests for DLLs will not be used automatically after loading the DLL, so you will have to do it manually when you need the COM-reg-free manifest, i.e. Before CoCreateInstance .

I had a case where I thought I knew when CoCreateInstance was called, and I needed a switch, but only later it turned out that the DLL spawned some stream (s) that they themselves used CoCreateInstance. (Where I could not control the activation context.)

So, to summarize, I would say:

• If you can do this at all, include the SxS COM manifest in the executable
• You can use the activation context API if you are fully aware, and you can control when you need to switch the context ("manually"), but this seems much more complicated than just embedding the manifest in the executable.