[Mono-bugs] [Bug 57602][Blo] New - Mono major assembly loader issues
Sun, 25 Apr 2004 03:27:53 -0400 (EDT)
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 firstname.lastname@example.org.
--- 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 @@
+Product: Mono: Runtime
+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
+let's assume the following dependency tree :
+ -> 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
+1) This issue can be reproduce both at runtime and at the compilation
+To reproduce this issue at runtime, just run a.exe without arguments using
+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")
+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
+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;" />
+ 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
+- 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).