Re: Complex Problem with AppDomains, Assembly Loading Contexts and COM Interop

Tech Tip: Click here to run a free scan for Windows Errors and optimize PC performance


<andrew.miadowicz@xxxxxxxxx> wrote in message
news:1156544208.532468.270100@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
My team has been struggling with an issue involving assemblies
dynamically loaded into separate app domains in the context of an .Net
extension running in a third party executable via COM Interop. After


.. . .


1. Nothing that I found online or in Steven's book explains what
exactly the COM Interop layer does when creating the CLR to load a the
first .Net assembly. Specifically, I have no clue how the CLR knows to
look for the assembly in the specific directory that actually contains
it. Naturally, such information would be available from Windows
Registry, but I can't seem to find anything that would instruct the CLR
to load such an assembly. Does the COM Interop layer actually
explicitly load the assembly into the CLR by passing the full path and
effectively executing LoadFrom?

2. If, in fact, a LoadFrom is executed, does the COM Interop attempt to
load the assembly by the usual CLR means of looking under the main
executable's directory FIRST? This would explain why copying the dlls
into the executable's directory actually loads them into the default
loading context.



From your description, it looks like if you can get your COM-visible
assembly to load into the default load context instead of the LoadFrom
context, that would be progress.

You can. Just sign and GAC your COM-visible assemblies.

Here's a fusion log from COM interop against a GAC'ed assembly

Notice the host is c:\windows\system32\wscript.exe, yet it's using the
default load context.

*** Assembly Binder Log Entry (8/30/2006 @ 4:10:17 PM) ***

The operation was successful.
Bind result: hr = 0x0. The operation completed successfully.

Assembly manager loaded from:
C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\mscorwks.dll
Running under executable C:\WINDOWS\System32\WScript.exe
--- A detailed error log follows.

=== Pre-bind state information ===
LOG: User = NORTHAMERICA\dbrowne
LOG: DisplayName = ComLoadContextTest, Version=1.0.0.0, Culture=neutral,
PublicKeyToken=ba7f46e71788619e
(Fully-specified)
LOG: Appbase = file:///C:/WINDOWS/System32/
LOG: Initial PrivatePath = NULL
LOG: Dynamic Base = NULL
LOG: Cache Base = NULL
LOG: AppName = WScript.exe
Calling assembly : (Unknown).
===
LOG: This bind starts in default load context.
LOG: Download of application configuration file was attempted from
file:///C:/WINDOWS/System32/WScript.exe.config.
LOG: Configuration file C:\WINDOWS\System32\WScript.exe.config does not
exist.
LOG: No application configuration file found.
LOG: Using machine configuration file from
C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\config\machine.config.
LOG: Post-policy reference: ComLoadContextTest, Version=1.0.0.0,
Culture=neutral, PublicKeyToken=ba7f46e71788619e
LOG: Found assembly by looking in the GAC.
LOG: Binding succeeds. Returns assembly from
C:\WINDOWS\assembly\GAC_MSIL\ComLoadContextTest\1.0.0.0__ba7f46e71788619e\ComLoadContextTest.dll.
LOG: Assembly is loaded in default load context.

David


.

Relevant Pages

  • Re: Make a DLL in C# for FoxPro
    ... Interop from managed -> COM is a different story, here we are talking about new developments, and here you have probably accepted the larger memory footprint :-) ... The first is handled by the DLL/C++ code I posted which loads the .NET runtime and allows loading of assemblies and types. ... If you're not adverse to registering components you can completely skip this step and just use the .NET wrapper component from FoxPro with CreateObject. ... *** Load Static Method ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Force Load DLL From Different Dir?
    ... try load the version MyAddIn bound to at compile time. ... Actually this is NOT version related, but context related: Assemblies can ... Microsoft Online Community Support ...
    (microsoft.public.dotnet.framework)
  • Re: Complex Problem with AppDomains, Assembly Loading Contexts and COM Interop
    ... ..Net assemblies get loaded by the CLR as the result of interop, ... and this allows us to load the assemblies into the Load context. ... default load context and in another is reachable only via the LoadFrom ... effectively executing LoadFrom? ...
    (microsoft.public.dotnet.framework.clr)
  • Re: Complex Problem with AppDomains, Assembly Loading Contexts and COM Interop
    ... I don't believe the basic problem is related to COM interop, ... default load context and in another is reachable only via the LoadFrom ... One workaround is to install all assemblies in the GAC but I personally ... The mechanism I used to avoid the Load versus LoadFrom problem was whenever ...
    (microsoft.public.dotnet.framework.clr)
  • Re: fuslogvw question
    ... Keep the result in LoadFrom context. ... Assembly is loaded in LoadFrom load context. ... All assemblies loaded during JIT compilation end up in this context. ... The second context is the "LoadFrom Context". ...
    (microsoft.public.dotnet.framework)