[Mono-bugs] [Bug 57602][Blo] New - Mono major assembly loader issues

[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=57602

--- shadow/57602	2004-04-25 03:27:53.000000000 -0400
+++ shadow/57602.tmp.15108	2004-04-25 03:27:53.000000000 -0400
@@ -0,0 +1,125 @@
+Bug#: 57602
+Product: Mono: Runtime
+Version: unspecified
+OS: 
+OS Details: 
+Status: NEW   
+Resolution: 
+Severity: 
+Priority: Blocker
+Component: misc
+AssignedTo: mono-bugs@ximian.com                            
+ReportedBy: gert.driesen@pandora.be               
+QAContact: mono-bugs@ximian.com
+TargetMilestone: ---
+URL: 
+Cc: 
+Summary: Mono major assembly loader issues
+
+I've stumbed upon the following major differences between the MS.NET and 
+Mono assembly loader :
+
+1) 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.dll
+    -> 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).
+
+This also affects the compile process : using csc, you only need to 
+reference assembly "b" to build assembly "a".  But using mcs, you need to 
+reference both assembly "b" and "c" to build assembly "c".
+
+2) Mono currently does not use the privatePath specified in the 
+configuration\runtime\assemblyBinding\probing element (see c.exe.config in 
+attached tar) to resolve assembly references.
+
+Now, I've attached a tar file which will allow you to reproduce both 
+issues :
+
+1) This issue can be reproduce both at runtime and at the compilation 
+phase.
+
+runtime
+-------
+To reproduce this issue at runtime, just run a.exe without arguments using 
+Mono :
+
+mono a.exe
+
+This will fail on Mono as it will try to load assembly "c", but can't find 
+this.  This succeeds on MS.NET as only assembly "b" is directly referenced 
+by assemby "a", and this assembly can indeed be loaded (as its in the same 
+directory as assembly "a")
+
+compile
+--------
+To reproduce this issue during compilation, just try to build a.exe 
+without referencing assembly "c" :
+
+mcs /target:exe /out:a.exe /r:b.dll a.cs
+
+This will fail as Mono immediately tries to load assembly "c" too, and it 
+can't find this ofcourse.
+
+Again, this works fine using csc :
+
+csc /target:exe /out:a.exe /r:b.dll a.cs
+
+To build assembly "c" using mcs you must use this (notice that I added a 
+reference for assembly "c" before the reference to assembly "b") :
+
+mcs /target:exe /out:a.exe /r:assembly-c/c.dll /r:b.dll a.cs
+
+2) On both MS.NET and Mono, running a.exe with a random argument will 
+fail :
+
+eg. (mono) a.exe justsometest
+
+as in that case (when at least one argument is specified) a.exe will 
+instantiate a class in assembly "b", which itself also instantiates a 
+class in assembly "c". And as assembly "c" is not in the privatepath that 
+is probed for assembly references, both MS.NET as Mono fail to locate 
+assembly "c", which is correct behaviour for both.
+
+Now, there are actually two ways to have the runtime locate assembly "c" 
+(without moving it to the same directory as assembly "a" and "b") :
+
+- Specify additonal directories that the runtime should probe for 
+assemblies in the privatePath attribute of the 
+configuration/runtime/assemblyBinding/probing element in the application 
+configuration file :
+
+        <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
+            <probing privatePath="assembly-c;" />
+        </assemblyBinding>
+
+    I included a config file in the tar, just rename app.config to 
+a.exe.config and execute a.exe again with a random argument :
+
+    eg. (mono) a.exe justsometest
+
+    This will succeed on MS.NET, but will still fail on Mono.  I assume 
+Mono does not use add the directory in the privatePath attribute to the 
+probing path.
+
+- Use the AppDomain.AppendPrivatePath method to add an additional 
+directory to the private loader path, can you test this by passing 
+the "assembly-c" directory (which contains assembly "c") as argument to 
+a.exe, as the first argument that is passed to a.exe will actually be 
+appended to the private path.
+
+eg. (mono) a.exe assembly-c (after first moving/renaming the application 
+configuration file again)
+
+This will succeed on MS.NET (to ensure this), but will fail on Mono 
+(because of issue 1).