"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
>
>

"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