Re: fuslogvw question

Tech-Archive recommends: Speed Up your PC by fixing your registry

"gs" <gs@xxxxxxxxxxxxxx> wrote in message
news:Ou5ExiSiGHA.3408@xxxxxxxxxxxxxxxxxxxxxxx
what do the first and last log entries below mean? what do I have to do?
LOG: Where-ref bind Codebase does not match what is found in default
context. Keep the result in LoadFrom context.
LOG: Binding succeeds. Returns assembly from
D:\data\IeI\gp\AppCom\IeStringClassProd\IeStringClass\bin\Release\IeStringClass.dll.
LOG: Assembly is loaded in LoadFrom load context.

The runtime managed "load contexts" to determine if an assembly was loaded
already or not.

The most important context is the "Load Context", also called "Default
Context". This context maps assembly names (name, version, culture,
publickeytoken) to loaded assemblies. Before a new assembly is loaded into
this context, the runtime checks if an assembly with the same name has been
loaded already. When this is the case, the loaded assembly will be used and
the assembly will not be loaded twice.

All assemblies loaded during JIT compilation end up in this context. The JIT
compiler loads assemblies, if a type from a referenced assembly is used and
the assembly has not been loaded so far. Assemblies loaded via Assembly.Load
end up in this context, too. Since version 2, even assemblies loaded via
Assembly.LoadFrom can end up in this context.

The second context is the "LoadFrom Context". This context maintains a
mapping from codebases to loaded assemblies. In v1 and v1.1, all assemblies
loaded via Assembly.LoadFrom ended up in this context. This could easily end
up in situatins where an assembly was loaded twice:
Put and assembly in the GAC and the application directoy, call Assembly.Load
and it will be loaded from the GAC into the "Load Context", call
Assembly.LoadFrom giving the path to the assembly in the application
directory and it will be loaded again. Objects created from on loaded
assembly would not be compatible to their own types from the other loaded
assembly. (A cast from a Person object to a Person reference can easily
cause an InvalidCastException in this scenario).

To reduce these problems, the behavior of Assembly.Load has been changed:
Assembly Load now uses the codebase to first determine the assembly name of
the required assembly. Then it searches the assembly via the Assembly.Load
rules. If an assembly already exists in the Assembly.Load context, there is
no need to load it again. If not, it performs the normal assembly
resoulution to get the codebase for the Assembly.Load context. If this
codebase leads to an assembly with the requested name, it will load it into
the detault load context. Othewise it will load the via the codebase into
the LoadFrom context.

It is likely that exactly is has happened in your scenario: It seems that in
your code, you try to load IeStringClass.dll via
Assembly.LoadFrom("D:\data\IeI\gp\AppCom\IeStringClassProd\IeStringClass\bin\Release\IeStringClass.dll");
Assembly.LoadFrom uses this path to determine the assembly name, let's
assume "IeStringClass, Version=2.0.0.0, ..."
Now it checks if the assembly has been loaded into the Assembly.Load
context. Let's assume this is not the case.
Now it tries to resolve the assembly via the normal rules. Let's assume, it
finds a candidate "D:\YourApp\IeStringClass.dll".
Now it compares the name of the found assembly with the required assembly
name. Let's assume the assembly name of "D:\YourApp\IeStringClass.dll" is
"IeStringClass, Version=1.0.0.0".
Notice the the assembly found via assembly resoultion does not have the
required version number. That's why your log file says:

"LOG: Where-ref bind Codebase does not match what is found in default
context. Keep the result in LoadFrom context."

Therefore the assembly will not be loaded from
"D:\YourApp\IeStringClass.dll"
into the default context, but from
"D:\data\IeI\gp\AppCom\IeStringClassProd\IeStringClass\bin\Release\IeStringClass.dll"
Into the LoadFrom context.

That's why you log says:
"LOG: Assembly is loaded in LoadFrom load context."

Hope this helps

Marcus Heege
DevelopMentor


.

Relevant Pages

  • 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: Some interop Questions - C# to unmanaged DLL
    ... Additional information: Unable to load DLL 'SampleC.dll': This application ... (Exception from HRESULT: ... it is recommended that the LoadFrom context be avoided. ... done by installing assemblies in the Global Assembly Cache or in the ...
    (microsoft.public.dotnet.languages.csharp)
  • 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: 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: Managed DirectX SDK December 2005 breaks my build
    ... > Managed DirectX and Game Programming Resources ... >> Error 90 The name 'TextureLoader' does not exist in the current context ... >> (are you missing a using directive or an assembly reference?) ... >>> references to the assemblies get changed. ...
    (microsoft.public.win32.programmer.directx.managed)