Re: fuslogvw question by Marcus
Marcus
Tue Jun 06 12:44:58 CDT 2006
Hi gs,
"gs" <gs@dontMail.telus> wrote in message
news:OpJ0SmYiGHA.1260@TK2MSFTNGP05.phx.gbl...
> 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" <NOSPAM@heege.net> wrote in message
> news:ercvkFUiGHA.4200@TK2MSFTNGP05.phx.gbl...
>> "gs" <gs@dontMail.telus> wrote in message
>> news:Ou5ExiSiGHA.3408@TK2MSFTNGP05.phx.gbl...
>>> 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
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