# Wednesday, 09 June 2004
« Eclipse | Main | Another Snapshot »
AppDomains, Domain Neutral Assemblies and a Framework Bug

I came across an nasty bug in the Microsoft .NET Framework 1.1 today.

Here is a program that reproduces the problem:

using System;
using System.Reflection;

class Class1
{
  [LoaderOptimization(LoaderOptimization.MultiDomain)]
  static void Main(string[] args)
  {
    if(AppDomain.CurrentDomain.FriendlyName != "My 2nd Domain")
    {
      AppDomain dom = AppDomain.CreateDomain("My 2nd Domain");
      dom.ExecuteAssembly(Assembly.GetEntryAssembly().Location);
    }
    Console.WriteLine(AppDomain.CurrentDomain.FriendlyName);
    Console.WriteLine(typeof(Class1).TypeHandle.Value);
    new System.Data.RowNotInTableException();
    foreach(Assembly a in AppDomain.CurrentDomain.GetAssemblies())
    {
      Console.WriteLine(a.FullName);
    }
  }
}

In the 2nd AppDomain (the first one that prints), the list of assemblies doesn't contain System.Data, even though it clearly is present in the AppDomain, after all, the new System.Data.RowNotInTableException() was just executed.

The problem only occurs when assemblies are shared across AppDomains (this is what the [LoaderOptimization(LoaderOptimization.MultiDomain)] attribute does). Comment out that line and the program works as expected.

I think that this effectively means that IKVM cannot be used inside of ASP.NET, which, I believe, always loads assemblies domain neutral.

In the May 2004 Community Technology Preview of Visual Studio 2005, the bug is fixed and the above program performs as expected.

Wednesday, 09 June 2004 16:33:52 (W. Europe Daylight Time, UTC+02:00)  #    Comments [0] Tracked by:
"adipex buy cheap diet pill" (adipex buy cheap diet pill) [Trackback]
"three card poker free online" (three card poker free online) [Trackback]