I have the following scenario:

My domain classes and hbm.xml mapping files are both contained in a dll called DomainModel.dll.

However, due to the nature of my application, the DomainModel.dll is not known at compile time, but is loaded at runtime, like so:

Assembly domainModel = Assembly.LoadFrom("c:\plugins\DomainModel.dll");

However, it seems that NHibernate is unable to resolve any class names in the mapping files, even though they are fully qualified. It throws MappingException errors saying that it cannot find the class. The exception is thrown from ReflectHelper.cs, line 205. This seems to be a problem with the System.Type.GetType(...) method, which does not seem to work when the type is located in an assembly that was not referenced at compile time.

Can anyone explain this and/or suggest a possible solution?

Thanks,
Jonathan

Do you build the sessionfactory after loading the domain assembly?

To make things work you at least have to add the assembly to the configuration (for example with Configuration.AddAssembly()). If you build the sessionfactory after that, things should be fine.

See http://blogs.msdn.com/suzcook/archive/2003/05/29/57143.aspx and http://www.gotdotnet.com/team/clr/LoadFromIsolation.aspx for explanations. I don't know of a solution currently.

Thanks for the blog links - they were helpful! The solution I have found is that if I put the NHibernate.dll and related libraries in the same folder as my DomainModel.dll, then it is able to resolve the classes.

Actually that isn't the whole story. For the benefit of anyone else who may encounter this issue, I'll describe the full solution.

Originally we had 2 assemblies: the application (call it Application.exe) and the DomainModel.dll. Application.exe had a static reference to NHibernate, but would load DomainModel.dll at runtime using Assembly.LoadFrom("c:\plugins\DomainModel.dll"). However, NHibernate was unable to resolve the classes in DomainModel.dll, because as a statically linked assembly it does not have access to types contained in assemblies loaded with LoadFrom. (See http://www.gotdotnet.com/team/clr/LoadF ... ation.aspx for more detail).

In order to work around this, we changed Application.exe to Application.dll and created a third assembly (call it Loader.exe) that loads both Application.dll and DomainModel.dll using LoadPath. Then, since Application.dll holds the static reference to NHibernate.dll, NHibernate is also loaded into the LoadPath context, and therefore has access to the types contained in DomainModel.dll.