[Mono-bugs] [Bug 57602][Wis] Changed - 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-26 11:22:50.000000000 -0400
+++ shadow/57602.tmp.32488	2004-04-26 11:45:23.000000000 -0400
@@ -163,6 +163,38 @@
 you run mcs on the csc runtime.
 
 I fail to see why this is `quite a serious issue'. At best, it is a 
 perf issue -- we load too many assemblies. It should be fixed, no 
 doubt. It is just probably not a `blocker'. And as I stated, the MCS 
 part of it is probably a WONTFIX
+
+------- Additional Comments From gert.driesen@pandora.be  2004-04-26 11:45 -------
+The compiler issue is more like an annoyance, but the runtime issue 
+actually is a blocking issue for NAnt.  We have a dependency for 
+log4net which comes in the flavor for Mono and one for .NET, but in 
+order to have a single binary release, we actually construct a 
+privatebinpath at runtime depending on the framework we're running on.
+
+NAnt.exe does not reference the log4net assembly, this app actually 
+just creates a new appdomain for the NAnt.Core assembly (which does 
+reference the log4net assembly). And this new appdomain is created 
+with a private path which matches the framework on which NAnt is 
+running.
+
+As a result, if running on Mono we use the lib;lib/mono and 
+lib/mono/1.0 as privatepath, and if running on, for example, .NET 1.0 
+we use lib;lib/net;lib/net/1.0 as privatepath.  As a result, if NAnt 
+is running on .NET it will, for example, automatically use the 
+log4net assembly in the lib/net/1.0 directory.
+
+Meaning, we can have a single binary release, and still allow 
+framework-specific assemblies to be used. Instead of having to create 
+a release for each specific supported framework.
+
+This works fine on .NET, but on Mono the runtime immediately tries to 
+resolve the reference for the log4net assembly (although the NAnt.exe 
+assembly does not reference it), meaning it has to be in the private 
+path from the start. Making it impossible to use a framework-specific 
+version of the log4net assembly.
+
+But as you've said, there's also a performance penalty for 
+immediately resolving the completely assembly dependency tree.