Question regarding Activation Context API: lpAssemblyDirectory use (Registration-free COM)

  • Thread starter Thread starter jlbradley1844
  • Start date Start date
J

jlbradley1844

Hello,

I'm attempting to apply Registration-free COM Activation Context API
and I'm having a heck of a time doing it. The problem seems to be the
way the API works - or doesn't work, as it were. The CreateActCtx does
not seem to pay proper attention to the lpAssemblyDirectory in the
ACTCTX structure - it seems to ignore this when loading the libraries
but not the manifest.

Here's the background: we are using a COM component that is called by a
user's browser (such as IE). Our COM component in turn calls some other
3rd-party COM components provided by other companies. We'd like to use
registration-free COM for these 3rd party libraries, since those
companies haven't been following COM rules for GUIDs and keep getting
"DLL Hell" problems from the field. Since we don't control the EXE, we
obviously can't go installing a .manifest files and .dlls in their
browser's execution directory. So this solution is to use the
Activation Context API to set up an activation context within our COM
object.

All seems to work, but as I state above, I cannot get the API to load
the DLLs from the directory supplied in ACTCTX's lpAssemblyDirectory
structure to CreateActCtx (yes, I remembered to use the flag
ACTCTX_FLAG_ASSEMBLY_DIRECTORY_VALID). It seems the .manifest file
needed is properly loaded directory specified in lpAssemblyDirectory,
but when a CoCreateInstance fails because the OS is still trying load
the COM objects from the directory the EXE is located in. I know this
because I can see the error messages telling me this when I profile
this under depends.exe. On the other hand, if I copy the 3rd party
libraries into the same directory as the EXE, everything works great.

I was able to replicate this behavior by using the sample programs
supplied in the White/Muller paper and adding the use of
lpAssemblyDirectory, so it isn't anything weird we're doing. (The
White/Muller paper is at
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dndotnet/html/rfacomwalk.asp).

I opened an incident with Microsoft last Thursday but still have not
gotten any resolution (in fact, I have heard little more than an e-mail
acknowledgement :-( ). Has anyone else out there had any luck getting
the lpAssemblyDirectory of the Activation Context API to work? This
seems like a simple operation, and I can't believe we're the only
people that have run into this problem.

Thanks much,

Joe Bradley
 
In the odd chance someone else runs into this problem, here's what's
going on. I got through to microsoft support and this is actually due
to a bug. Fortunately, there is a workaround.

I had all of my information in a single manifest file; i.e., the "root"
manifest file. There shouldn't be a problem with that per se, but for
the bug. If the DLL declarations are in the "root" manifest, then it
seems the directory value is ignored and it still tries to pull the
assembly from the directory with the executable in it.

As you might guess, the workaround is to place all your DLL
declarations in a separate manifest file, and make the root manifest
pull in that file as a dependency. Once you do that, it will load the
DLL from the directory you supplied.

Hope this helps someone,

Joe Bradley
 
Back
Top