Groups | Blog | Home
all groups > dotnet clr > august 2003 >

dotnet clr : Assembly.LoadFrom returns Assembly with "incorrect" Location and CodeBase


Sean Winstead
8/21/2003 12:30:45 PM
When I load an assembly using
Assembly.LoadFrom("C:\temp\sumdumAssembly.dll"), the assembly is
loaded and its FullName property identifies it as the correct
assembly. However, the Location and CodeBase properties point to the
assembly that called Assembly.LoadFrom.

I have read the article titled "Application Isolation and
Assembly.LoadFrom" but it did not appear to address this issue.

Does anyone know why the aforementioned behavior occurs?

--
Sean Winstead
Peter Allwin [MSFT]
8/21/2003 6:11:18 PM
Sean,

It sounds to me like the wrong assembly gets loaded. Assembly.LoadFrom does
not gurantee the assembly you load will be the same one you specified.
Basically it extracts the assembly info from the assembly you specified, and
it will return the assembly you specified only if it cannot find any
assembly with the same assembly info from high priority places (like the
GAC).

If you are using version 1.1 of the Framework (VS 2003) you can use
Assembly.LoadFile which circumvents this behavior.


Best Regards,

Peter Allwin


This posting is provided "AS IS" with no warranties, and confers no rights.


[quoted text, click to view]

Alan Shi [MSFT]
8/21/2003 7:43:53 PM
Actually, this is not quite true. LoadFrom will give you the assembly you
specify (even if it is found in the GAC, or other locations), however, you
cannot load two assemblies with the same identity via LoadFrom in the same
domain. For example, say 'myassembly' is a strongly-named assembly and I
deploy it to two locations, c:\first-location, and c:\second-location.
Assume your appbase is c:\appbase. Issuing:

Assembly.Load("c:\first-location\myassembly.dll")
Assembly.Load("c:\second-location\myassembly.dll")

....will cause myassembly to only be loaded from c:\first-location.

The behaviour you are referring to (e.g. if you LoadFrom an assembly, and
the same assembly, from the same location would have been found via
probing), only determines which load context the assembly gets put in.

As you mention, LoadFile is a potential workaround.

..\lan

--
This posting is provided "AS IS" with no warranties, and confers no rights.
http://blogs.gotdotnet.com/alanshi


[quoted text, click to view]

Peter Allwin [MSFT]
8/21/2003 8:43:22 PM
Thanks for clarifying :)

--
Best Regards,

Peter Allwin


This posting is provided "AS IS" with no warranties, and confers no rights.

[quoted text, click to view]

Sean Winstead
8/22/2003 8:49:03 PM

[quoted text, click to view]

Thanks to you and Alan for the information. I'm pretty sure it has the
correct assembly. I say this because once the assembly is loaded, the
code reflects through the assembly's types and it does find the
correct types. We have tested this on at least one clean machine and
the same behavior occurs.

My workaround was simple. The only reason I needed things like
Location and CodeBase is because I needed to get the loaded assembly's
AssemblyName. I was able to get the AssemblyName via another route.

--
Sean Winstead
AddThis Social Bookmark Button