6

At the moment I have something like this for a registration-free COM setup:

  • a.exe (depends on b.dll; does not directly depend on c.dll)
  • a.exe.manifest (declares registration-free COM registration for c.dll)
  • b.dll (depends on c.dll. For example, a .NET TMBIMP generated COM wrapper)
  • c.dll (some COM implementation DLL)
  • c.dll.manifest (registration-free COM manifest for c.dll)

Is it possible to change this scheme such that the manifest that is on a.exe is instead placed on b.dll? I'd like other programs to be able to reference b.dll without having to add additional manifests everywhere if possible.

(a.exe.manifest has this content:

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

)

and c.dll.manifest was generated using the manifest tool mt.exe. (and is far too long to include here)

Billy ONeal
  • 104,103
  • 58
  • 317
  • 552
  • Use activation context API to control which manifests are active at the point of load. – David Heffernan Apr 03 '14 at 01:49
  • Technically, yes. Not without a load of trouble, b.dll is an auto-generated file so you'll have to take control over that and monkey with mt.exe to embed the manifest. Use ID 2. The .NET 4 Embed Interop Types feature is also very troublesome, highly desirable but it makes b.dll disappear. – Hans Passant Apr 04 '14 at 16:02
  • @Hans: In this case `b.dll` isn't autogenerated. (`tlbimp` gets quite a lot wrong here and we had to decompile, mess with the IL, and recompile) – Billy ONeal Apr 09 '14 at 21:56
  • @BillyONeal, yes, it's possible. You can even have manifests that only contain dependencies, and manifests that refer to more than one DLL. – acelent Apr 12 '14 at 14:18
  • possible duplicate of [Move manifest file to dll?](http://stackoverflow.com/questions/17942999/move-manifest-file-to-dll) – Martin Ba Apr 29 '14 at 11:28
  • @Martin: That question discusses LoadLibrary, not Registration-Free COM. – Billy ONeal Apr 29 '14 at 19:30
  • That question asks how to embed a manifest for reg free COM into a DLL that is eventually loaded via LoadLibrary. As far as I can tell, whether you link dynamically=LoadLib or statically shouldn't matter. – Martin Ba Apr 30 '14 at 19:14
  • @Martin: It does matter. In one case you're providing a DLL name to LoadLibrary and asking the loader to respect a manifest setting. In another case you're asking COM to respect a manifest file on the file system. This isn't a loader setting, this is a COM setting. – Billy ONeal Apr 30 '14 at 22:00
  • I'd say it's not a COM setting, it's an Activation Context setting. Anyway. In your case, when you have `b/c.dll.manifest` who do you think would be responsible for respecting the manifest (file) of the dll? The DLL will be loaded by the "loader" and if that machinery doesn't put the manifest into the applications Activation Context, then it wont be used. And as far as *I* know, the loader will *not* do anything about reg-free COM manifest stuff, although it *will* check the manifest of the DLL for DLL dependencies (like msvcr etc.). – Martin Ba May 01 '14 at 16:26

1 Answers1

0

My experience is that it doesn't work, or rather you need to call into the Activation Context API to make actual use of the manifest in a DLL: See this question: Move manifest file to dll?

My take on this, although maybe not entirely accurate, is this:

  • Registry based COM is "global" per user

  • Regfree manifest COM is "global" per process and should be managed on the executable.

Only the executable manifest is always "in scope", if you're DLLs have a COM side-by-side manifest, you are forced to load this explicitly using the Activation Context API, and the problem with that is that it can only work when you know exactly when it is needed and control the call path to the places in the DLL where it is needed.

Because, as I understand this, what you really do when you have "a.exe.manifest (declares registration-free COM registration for c.dll)" is that you modify the initial/global Activation Context of that process. This (seems to) only works for the executable manifest. Any manifests for the DLLs won't be in use automatically after the DLL is loaded, so you'll have to do it manually when you need the reg-free COM manifest in place, i.e. before CoCreateInstance.

I had a case where I thought that I knew when CoCreateInstance was called and I needed the switch, only to later discover that the DLL spawned some thread(s) that did some CoCreateInstance themselves. (Where I couldn't control the Activation Context of.)

So to sum up I'd say:

  • If you can do at all, include the SxS COM manifest in you executable
  • You can use the Activation Context API if you know fully and can control when to switch the context ("manually"), but this seems so much more hassle compared to just embedding the manifest in the executable.
Community
  • 1
  • 1
Martin Ba
  • 37,187
  • 33
  • 183
  • 337
  • So, your answer is, "Yes, if the .EXE knows in advance" which defeats the purpose of putting it on the DLL in the first place. – Billy ONeal May 20 '14 at 19:04
  • @BillyONeal: I say *technically* there are cases where the EXE doesn't need to know anything, but as far as I can grasp this whole thing, *in practice* the only thing that properly works is putting the manifest in the EXE. (But we already discussed this in the comments to the question, no?) – Martin Ba May 21 '14 at 07:22
  • @BillyONeal: But you see, I'm *very* far from calling me an expert on that whole matter, so I am genuinely interested in finding a definite answer myself. So if we are in disagreement over some basics (as it seems to me from our comment discussion) I'm happy to talk about it some more. – Martin Ba May 21 '14 at 07:24