Hi Atul,
Thanks for your post!!
Based on my understanding, you want to get some detailed information about
how CLR resolves used method from a referenced assembly.
Normally, .Net uses dynamically loading technology in Win32 world. That is
the referenced code is not embeded in the exe's file. For .Net exe
assembly, it resolves the assembly reference, type reference, method
reference at load time(this only applies when you are not doing explicit
loading with Assembly.Load or Assembly.LoadFr om method).
If the assembly you referenced is a strong named, CLR will resolve all the
strong name information(tha t is all of assembly file name, version,
cultrual and PublicKeyToken) , so if you replace a new compiled version of
the assembly in the CLR probing path, CLR will still load the original
assembly. This is called Side-by-Side execution in .Net, for more
information please refer to:
"Side-by-Side Execution"
http://msdn.microsoft.com/library/de...us/cpguide/htm
l/cpconside-by-sideexecutionto p.asp
For not strangly named assembly, CLR will ignore the version information,
only use the assembly file name for loading, so it may load the new version
assembly. Below is a little test for this:
//Exe assembly
static void Main(string[] args)
{
testclass.Class 1 obj=new testclass.Class 1();
obj.testmethod( );
}
//Original dll assembly
public class Class1
{
public Class1()
{
}
public void testmethod()
{
Console.WriteLi ne("abc");
}
}
//new version dll
public class Class1
{
public Class1()
{
}
public void testmethod()
{
Console.WriteLi ne("abc2");
}
public void testmethod2()
{
Console.WriteLi ne("def");
}
}
If I replace the original dll with the new version, my exe file execution
will output "abc2" without any problem.
For more information, please refer to the article in "Suzanne Cook's .NET
CLR Loader" blog:
"Assembly Identity"
http://blogs.msdn.com/suzcook/archiv.../21/57232.aspx
"Avoid Partial Binds"
http://blogs.msdn.com/suzcook/archiv.../30/57159.aspx
Actually, internally, CLR uses the metadata and manifest information in the
assembly for the Loading process, for example, there is AssemblyRef field
in the assembly manifest, and the CLR will use AssemblyRef for the
referenced assembly probing and loading information. You can find more
detailed information in "Jeffrey Richter"'s wonderful book "Applied
Microsoft .Net Framework Programming", especially, there is a section named
"How the Rntime Resolves Type References" with a picture shows us how CLR
performance the type resolution.
So for your question, the answer is once the refered assembly's public
interface(such as type name, public methods name, public properties name
,etc), there is no need for the exe to do re-buiding. Also, the backward
compatibility is important, unless you are using side-by-side
execution.(Actu ally, side-by-side execution is the key component in .Net
that eliminate DLL Hell)
Currently, there is few official document about CLR Loader internal, I
think "Suzanne Cook's .NET CLR Loader" blog should be an invaluable
resource for this topic(she is the .Net CLR team SDE focused on CLR
Loader), please refer to:
http://blogs.msdn.com/suzcook
=============== =============== =============== =============== =============== =
========
Thank you for your patience and cooperation. If you have any questions or
concerns, please feel free to post it in the group. I am standing by to be
of assistance.
Best regards,
Jeffrey Tan
Microsoft Online Partner Support
Get Secure! -
www.microsoft.com/security
This posting is provided "as is" with no warranties and confers no rights.