Using Activation Context API with many dlls in different locations

4
votes

I am using Activation Context API in a .Net client running in a location A to load a COM component reg-free in location B (which is completely different location to A, not a sibling/descendent etc. on the same machine) on WS2008 by passing in location B in the ACTCTX and it works fine.

However, I now need to do the same thing with another COM dll which in turn has dependencies on a couple of .Net COM assemblies which live in completely different locations.

I have added the dependent .Net assemblies to the manifest and put the manifest and COM dll in location B but I have to put the dependent .Net assemblies in location A (where the client runs) to get it to work. In reality, they will live in completely different directories to location A and location B.

Is what I'm attempting to do possible, i.e. is it possible to load multiple COM components in different unrelated directories using activation context api?

1
comside-by-sideregfreecomactivation-context-api
Very doubtful, the only .NET awareness in activation context is the <clrClass> element in the manifest. Doesn't sound like that applies. The GAC or AppDomain.AssemblyResolve are workarounds. Not using local deployment in regfree COM is usually a mistake. – Hans Passant
Can it be done from the same directory even? – HankTheTank
you can attach to the AssemblyResolve event of your app-domain and load the dll on demand, no matter from which location – HankTheTank

1 Answers

5
votes

.NET looks at the active and process activation contexts to discover reg-free metadata (<clrClass>, etc) just like native COM does. Unlike native COM, however, it doesn't use the information contained in the activation context to determine the location of the actual files. There, I believe it looks only at the GAC, followed by locations of files next to the client EXE only. You can probably confirm this using Sysinternals Procmon. I'd imagine you could try the workarounds Hans suggested or pre-loading the needed assemblies manually into your process and see if that works; I didn't get to try this out as in my scenario the client exe was a native exe I didn't have control over.