Assembly linking

  • Thread starter Thread starter Atul Godbole
  • Start date Start date
A

Atul Godbole

Suppose an assembly "Main" is using class "A" from another Assembly "Dep" as
follows :

A a = new A();
a.MethodOne();

At what time is the call to MethodOne linked to the actual MSIL (method
body) of the method? Does this occur when "Main" is build or does it happen
when main is loaded and Jitted? Also is the linking achieved by the full
method name( this is what is seen in the IL generated by ILDASM : e.g : call
System.String.ctor() ) or is it linked using a fixed number ( say its
ordinal in the class function table).

The reason I am asking this is what will happen if I add another method
"MethodTwo" to class "A" without changing the version of the assembly "Dep".
Will the "Main" assembly continue to run without the need to recompile?

If so, this should suggest that at least some part of the linking is done
during load-time.

Any explanations, doc references, online article references would be
appreciated.

Regards
Atul
 
At what time is the call to MethodOne linked to the actual MSIL (method
body) of the method? Does this occur when "Main" is build or does it happen
when main is loaded and Jitted?
Click to expand...

Depends on what you mean by "linked". At compile time there's enough
information stored in the Main assembly to locate MethodOne in the A
class in the Dep assembly.

Also is the linking achieved by the full
method name( this is what is seen in the IL generated by ILDASM : e.g : call
System.String.ctor() ) or is it linked using a fixed number ( say its
ordinal in the class function table).
Click to expand...

By name and signature, no magic numbers.

The reason I am asking this is what will happen if I add another method
"MethodTwo" to class "A" without changing the version of the assembly "Dep".
Will the "Main" assembly continue to run without the need to recompile?
Yes.


If so, this should suggest that at least some part of the linking is done
during load-time.
Click to expand...

Well yes, the actual method to call is looked up by name at runtime.



Mattias
 
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.LoadFrom method).

If the assembly you referenced is a strong named, CLR will resolve all the
strong name information(that 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/default.asp?url=/library/en-us/cpguide/htm
l/cpconside-by-sideexecutiontop.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.Class1 obj=new testclass.Class1();
obj.testmethod();
}
//Original dll assembly
public class Class1
{
public Class1()
{
}

public void testmethod()
{
Console.WriteLine("abc");
}
}
//new version dll
public class Class1
{
public Class1()
{
}

public void testmethod()
{
Console.WriteLine("abc2");
}

public void testmethod2()
{
Console.WriteLine("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/archive/2003/07/21/57232.aspx
"Avoid Partial Binds"
http://blogs.msdn.com/suzcook/archive/2003/05/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.(Actually, 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.
 
Hi Atul,

Does my reply make sense to you? If you still have any concern, please feel
free to feedback, thanks

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.
 
Back
Top