[Mono-bugs] [Bug 62135][Maj] New - Assembly loader difference between Mono and .NET

[bugzilla-daemon@bugzilla.ximian.com]

Please do not reply to this email- if you want to comment on the bug, go to the
URL shown below and enter your comments there.

Changed by gert.driesen@pandora.be.

http://bugzilla.ximian.com/show_bug.cgi?id=62135

--- shadow/62135	2004-07-30 08:49:17.000000000 -0400
+++ shadow/62135.tmp.20875	2004-07-30 08:49:17.000000000 -0400
@@ -0,0 +1,93 @@
+Bug#: 62135
+Product: Mono: Runtime
+Version: unspecified
+OS: All
+OS Details: 
+Status: NEW   
+Resolution: 
+Severity: 
+Priority: Major
+Component: misc
+AssignedTo: jackson@ximian.com                            
+ReportedBy: gert.driesen@pandora.be               
+QAContact: mono-bugs@ximian.com
+TargetMilestone: ---
+URL: 
+Cc: 
+Summary: Assembly loader difference between Mono and .NET
+
+(I discussed this issue with Jackson and he agreed to set the priority to 
+Major)
+
+Mono immediately resolves the whole tree of assembly references 
+(meaning if loading an assembly "a", not only the assemblies referenced 
+by "a" are loaded but also all assemblies referenced by the assembly "a" 
+references), while MS.NET only immediately loads the direct assembly 
+references.
+
+let's assume the following dependency tree :
+
+a.exe
+    -> b.dll
+        -> c.dll
+
+when loading assembly "a", MS.NET will only immediately load 
+assembly "b".  Only when accessing types from assembly "c", it will load 
+that assembly (and its direct references).
+
+To reproduce this issue :
+
+- extract the zip file I've attached to this bug report
+- as you'll notice, assembly c is in a subdirectory to prevent the 
+runtime from being able to locate it
+- execute the a.exe assembly using Mono :
+
+$ mono a.exe
+
+You'll get the following output 
+
+** (a.exe:4804): WARNING **: Could not find assembly c, references from 
+d:\mono-test-projects\assembly-loading-simple\b.dll (assemblyref_index=1)
+     Major/Minor: 0,0
+     Build:       0,0
+     Token:
+
+** (a.exe:4804): WARNING **: Could not find assembly b, references from 
+d:\mono-test-projects\assembly-loading-simple\a.exe (assemblyref_index=1)
+     Major/Minor: 0,0
+     Build:       0,0
+     Token:
+
+cannot open assembly a.exe
+
+Mono is not able to execute anything in assembly a.exe, because assembly 
+c (which is referenced by assembly b) cannot be loaded.
+
+Now, when you execute the same app using .NET, you'll get the following 
+output:
+
+Loading assembly "b" ...
+Assembly "b" loaded ok.
+Initializing type in assembly "b" ...
+Type initialized ok.
+Invoking method which uses assembly "c" ...
+
+Unhandled Exception: System.IO.FileNotFoundException: File or assembly 
+name c, o
+r one of its dependencies, was not found.
+File name: "c"
+   at b.SomeClass.Test()
+   at a.SomeClass.Main(String[] args)
+
+As you can see, on .NET the app only fails when code in assembly c is 
+invoked.  
+
+So on .NET; the complete dependency tree does not have to be available 
+immediately, which allows applications to construct, for example, a 
+privatebinpath to allow the runtime to locate specific assemblies.
+
+Fixing this might also save that quite some cycles as assemblies are 
+loaded on demand.
+
+eg. When compiling assembly a using mcs, you would no longer need to load 
+assembly c.