fuslogvw question

[gs]

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.

 

[Marcus Heege]

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

 

[gs]

thank you very much for your detailed explanation. The resulting behaviour
seems to be what I need.

However, I am still at a loss.
I saw the same methods in the assembly with same OLEobject client code from
a native application worked in earlier runtime interpreter ( not dotnet
runtime but cstdcall runtime) but fails in the same application migrated to
use a later native runtime. the problematic methods has string array by
reference in the signature. other methods that do not involve arrays works
without binding problem

in my troubleshooting, I revised ieStringClass's help function returning a
string containing compiling date time, version. I invoke this help function
after connecting and found I was getting the right one.

BTW
1 what is in a configuration file? it seems that the newer native
application interpreter causes dotnet to look for configuration file
associated with he interpreter,
e:\programfiles\aVndr\SomeInterpretorv9\theExe.exe.config


2 How would one launch by path?

normally one would do something equivalent to
createobject(SomeProgIDorCLSID).


I also tried launching by clsid by it did not help

 

[Marcus Heege]

Hi gs,

thank you very much for your detailed explanation. The resulting
behaviour seems to be what I need.

However, I am still at a loss.
I saw the same methods in the assembly with same OLEobject client code
from a native application worked in earlier runtime interpreter ( not
dotnet runtime but cstdcall runtime) but fails in the same application
migrated to use a later native runtime. the problematic methods has
string array by reference in the signature. other methods that do not
involve arrays works without binding problem

in my troubleshooting, I revised ieStringClass's help function returning a
string containing compiling date time, version. I invoke this help
function after connecting and found I was getting the right one.

BTW
1 what is in a configuration file? it seems that the newer native
application interpreter causes dotnet to look for configuration file
associated with he interpreter,
e:\programfiles\aVndr\SomeInterpretorv9\theExe.exe.config


2 How would one launch by path?

normally one would do something equivalent to
createobject(SomeProgIDorCLSID).


I also tried launching by clsid by it did not help

to be honest, I am somewhat lost. Maybe you start your explanation again,
with a little more context to your original question and with some
information about the tools/languages you use (including their version
number).

Marcus