views:

1003

answers:

3

I was looking at the msdn documentation and I am still a little confused on what exactly is the difference between using LoadFile and LoadFrom when loading an assembly. Can someone provide an example or an analogy to better describe it. The MSDN documentation confused me more. Also, Is ReflectionOnlyLoadFrom the same as LoadFrom except that it loads the assembly only in reflection mode.

Since my .NET experience is not the greatest, here are some questions regarding the MSDN documentation using LoadFile:

1) What does it mean by LoadFile examines assemblies that have the same Identity, but are located in different paths? What is the identity (example)?

2) It states the LoadFile does not load files into the 'LoadFrom Context' and does not resolve dependencies using the load path. What does this mean, can someone provide an example?

3) Lastly, it states that LoadFile is useful in this limited scenario because LoadFrom cannot load assemblies that have the same identities but different paths; it will only load the first such assembly, which again brings me to the same question, what is the assemblies identity?

+4  A: 

Does this clear it up?

// path1 and path2 point to different copies of the same assembly on disk:

Assembly assembly1 = Assembly.LoadFrom(path1);
Assembly assembly2 = Assembly.LoadFrom(path2);

// These both point to the assembly from path1, so this is true
Console.WriteLine(string.Compare(assembly1.CodeBase, assembly2.CodeBase) == 0);

assembly1 = Assembly.LoadFile(path1);
assembly2 = Assembly.LoadFile(path2);

// These point to different assemblies now, so this is false
Console.WriteLine(string.Compare(assembly1.CodeBase, assembly2.CodeBase) == 0);


Edit: to answer the questions you raised in your revised question, you definitely want to read Suzanne Cook on Assembly Identity.

There are a lot of rules that govern how assemblies are loaded, and some of them have to do with how they resolve dependencies - if your AssemblyA is dependent on AssemblyB, where should .NET look to find AssemblyB? In the Global Assembly Cache, the same directory it found AssemblyA, or somewhere else entirely? Furthermore, if it finds multiple copies of that assembly, how should it choose which one to use?

LoadFrom has one set of rules, while LoadFile has another set of rules. It is hard to imagine many reasons to use LoadFile, but if you needed to use reflection on different copies of the same assembly, it's there for you.

Jeff Sternal
Is the CodeBase the same as the Identity?
Xaisoft
No, I just used CodeBase here as an arbitrary property of the assembly to illustrate that the second Assembly instance was pointing to the 'wrong' file (in the first example). I'm updating my answer with more details.
Jeff Sternal
It clears it up a bit, but how does path1 and path2 point to different copies of the same assembly on disk when using LoadFrom and when using LoadFile, path1 and path2 point to different assemblies. What is an example of what path1 and path2 would be? Thanks for your patience.
Xaisoft
Thanks for the link on Assembly Identity by the way.
Xaisoft
Thanks for the extra info, that cleared up a lot.
Xaisoft
+6  A: 

From Suzanne Cook's blog:

LoadFile vs. LoadFrom

Be careful - these aren't the same thing.

LoadFrom() goes through Fusion and can be redirected to another assembly at a different path but with that same identity if one is already loaded in the LoadFrom context.

LoadFile() doesn't bind through Fusion at all - the loader just goes ahead and loads exactly* what the caller requested. It doesn't use either the Load or the LoadFrom context.

So, LoadFrom() usually gives you what you asked for, but not necessarily. LoadFile() is for those who really, really want exactly what is requested. (*However, starting in v2, policy will be applied to both LoadFrom() and LoadFile(), so LoadFile() won't necessarily be exactly what was requested. Also, starting in v2, if an assembly with its identity is in the GAC, the GAC copy will be used instead. Use ReflectionOnlyLoadFrom() to load exactly what you want - but, note that assemblies loaded that way can't be executed.)

LoadFile() has a catch. Since it doesn't use a binding context, its dependencies aren't automatically found in its directory. If they aren't available in the Load context, you would have to subscribe to the AssemblyResolve event in order to bind to them.

See here.

Also see Choosing a Binding Context article on the same blog.

CraigTP
was'n fast enough +1
Arthur
Thanks, I will check out the blog, I updated my post with some questions regarding the msdn documentation.
Xaisoft
@Xaisoft - Suzanne Cook's blog comes to the rescue again with the answer of an Assemblies Identity. See http://blogs.msdn.com/suzcook/archive/2003/07/21/57232.aspx. It is essentially an "assembly display name" and this is something like: "System, Version=1.0.3300.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" so includes both the assembly's actual name, it's version number along with other identifying information (like PublicKeyToken etc.).
CraigTP
Curious, is Suzanne Cook the Reflection Guru :)
Xaisoft
What is she referring to when she talks about Fusion?
Xaisoft
Fusion is the .NET sub-system that locates and loads assemblies, and Suzanne Cook is its Guru. (Probably a general Reflection Guru too.) :)
Jeff Sternal
Indeed, Jeff is spot on. See this link: http://www.grimes.demon.co.uk/workshops/fusionWS.htm for a nice tutorial on the Fusion sub-system and it's technology for loading assemblies in .NET
CraigTP
+1  A: 

.NET has different load context. Suzanne Cook wrote about them here: http://blogs.msdn.com/suzcook/archive/2003/05/29/57143.aspx

This is the way .Net quarantines that references are not mixed up.

Arthur