Question

We have this really weird problem in a Web Application when using ActiveRecord 2.0 with NHibernate 2.1.0 (have also tried 2.1.2). I’m sorry if this description is a little vague, but we are having problems understanding exactly what is going on. We are working on a large enterprise application, where we are trying to isolate the problem and make a small example, but we have not accomplished this yet.

The problem occurs when we try to execute a special query over two objects with a many-to-one relationship. This is the code that will cause the problem:

int testItemId = 1;
TestItem testItem = ActiveRecordMediator<TestItem>.FindByPrimaryKey(testItemId, false);
DetachedCriteria testCriteria = DetachedCriteria.For<TestItemRevision>();
testCriteria.Add(Expression.Eq("TestItem", testItem));
TestItemRevision testRevision = ActiveRecordMediator<TestItemRevision>.FindFirst(testCriteria);

When executing FindFirst (or FindAll) the following exception is thrown:
Type mismatch in NHibernate.Criterion.SimpleExpression: TestItem expected type MyProduct.Core.DomainModel.Test.TestItem, actual type MyProduct.Core.DomainModel.Test.TestItem

As you can see, expected type == actual type.

We have found that this exception is thrown in NHibernate.Criterion.CriterionUtil.GetColumnNamesUsingPropertyName(…). We have compiled our own version of NHibernate, with some extra logging in here.
When everything is OK, we get this:

propertyType.ReturnedClass.Assembly: MyProduct.Core.DomainModel, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null
propertyType.ReturnedClass.Assembly.Location: C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files\root\daa38103\4727b73f\assembly\dl3\bb8c85b9\7202540f_a593ca01\MyProduct.Core.DomainModel.DLL
value.GetType().Assembly: MyProduct.Core.DomainModel, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null
value.GetType().Assembly.Location: C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files\root\daa38103\4727b73f\assembly\dl3\bb8c85b9\7202540f_a593ca01\MyProduct.Core.DomainModel.DLL

When the exception is thrown, we get this:

propertyType.ReturnedClass.Assembly: MyProduct.Core.DomainModel, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null
propertyType.ReturnedClass.Assembly.Location == String.Empty: True
value.GetType().Assembly: MyProduct.Core.DomainModel, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null
value.GetType().Assembly.Location: C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files\root\daa38103\4727b73f\assembly\dl3\bb8c85b9\7202540f_a593ca01\MyProduct.Core.DomainModel.DLL

Ie, when the exception is thrown, the expected type has no Location, and is treated as a different assembly.

The really weird thing is this: The exception is not always thrown. We have to recycle the Application Pool in IIS to reproduce the problem, and only about 1 out of 3 restarts will actually trigger it. We think that this query must be the first thing that happens after a restart, but we are not sure of this. After the exception has been thrown once, the query will not work again until the App Pool has been recycled, or the DLL in the bin-folder has been updated. Restarting the Web Site or changing the Web.config does not help. We have reproduced the problem on both WinServer 2003/IIS6 and Win7/IIS7.5.

We have tried to set up a test project with the exact same object mappings and the exact same query, but we have not been able to reproduce the problem outside of the large application yet. Does anyone have any clue on what might cause something like this?

Edit:

This is how we load our assembly, in global.asax Application_Start:

Assembly[] assemblies = new[] { Assembly.Load("MyProduct.Core.DomainModel") };
ActiveRecordStarter.Initialize(assemblies, ActiveRecordSectionHandler.Instance);

(This is a simplified version, we’re really loading our assembly names from config, but it’s not relevant for this problem.)

Answer 1

MSDN says that, for the Assembly Location property,

If the assembly is loaded from a byte array, such as when using the Load(array[]) method overload, the value returned is an empty string (“”).

That is, instead of loading the assembly from its file location on disk, somebody read into in an array of bytes and loaded it up that way. The google-tubes tell me that this would cause the assembly to be loaded with a different security context, and as such, it’s not surprising that NHibernate would see it as a different types.

Is it possible that you have some mechanism that could be loading the assembly in such a way, possibly in some kind of race condition? I’d try entering the rabbit hole from here. Good luck!