[Mono-dev] Version-specific binding - resolved, but real bugs found

[Brian Crowell]

Gonzalo Paniagua Javier wrote:
> Can you please file bug reports in bugzilla.ximian.com and attach a test
> case for these problems?

Turns out it's a false alarm on the second one. The properties on dynamic 
assemblies in .NET also throw exceptions, though I still think this behavior is 
bad design because it should be treated the same as if the assembly had been 
loaded as a bag-o-bytes.

On the first one, I found that the reason my implicitly-loading assemblies were 
not showing up is because the assemblies loaded into my first domain had 
propogated into the second one. So the bug here is not that the correct assembly 
wasn't being reported, it was that it wasn't even being loaded!

A quick example:

==============================================
using System;
using System.Reflection;

namespace Test {
     class TestClass {
         public static void Main( string[] args ) {
             AppDomain newDomain = AppDomain.CreateDomain( "testDomain" );
			
             foreach( Assembly assem in newDomain.GetAssemblies() ) {
                  Console.WriteLine( assem.FullName );
             }
         }
     }
}
==============================================

Under .NET, this program reports the following assembly in the new AppDomain:

   mscorlib, Version=1.0.5000.0, Culture=neutral, PublicKeyToken=b77a5c561934e089


Under Mono, these assemblies are reported:

   mscorlib, Version=1.0.5000.0, Culture=neutral, PublicKeyToken=b77a5c561934e089
   test-EmptyAppDomain, Version=0.0.0.0, Culture=neutral


It can be shown that any assembly found in the AppDomain that called 
CreateDomain ends up in the new domain.

This has been filed as bug #78648.

--Brian


-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: test-EmptyAppDomain.cs
Url: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20060614/e8c43183/attachment.pl