Kamil Kliczbor @ asptip.net

NHibernate processing *.hbm.xml order

Recently we had small problem with defining views in our mappings. Because we use mapping export to local MS-SQL database we needed to define the views in our *.xbm.xml files. The problem was arising when we wanted to have dependencies between views. First thing we thought it would make it work was to put the views in the order defined by hbm's names. That did nothing. Then we started to dig in the FluentNH code and we went deeper in NH then found these interesting lines of code in the Configuration.cs:

/// <summary>
/// Adds all of the assembly"s embedded resources whose names end with <c>.hbm.xml</c>.
/// </summary>
/// <param name="assembly">The assembly.</param>
/// <returns>This configuration object.</returns>
public Configuration AddAssembly(Assembly assembly)
{
	IList resourceNames = GetAllHbmXmlResourceNames(assembly);
	if (resourceNames.Count == 0)
	{
		log.Warn("No mapped documents found in assembly: " + assembly.FullName);
	}
	foreach (var name in resourceNames)
	{
		AddResource(name, assembly);
	}
	return this;
}

private static IList GetAllHbmXmlResourceNames(Assembly assembly)
{
	var result = new List<string>();

	foreach (var resource in assembly.GetManifestResourceNames())
	{
		if (resource.EndsWith(".hbm.xml"))
		{
			result.Add(resource);
		}
	}

	return result;
}

The answer was clear: the mappings are added to the queue (see class MappingsQueue.cs) and processed one by one in the order they were enqueued. And the order depends of the internal implementation of the GetManifestResourceNames method. Unfortunately this boils down to know the implementation of the method from System.Reflection.RuntimeAssembly that is quite hard to decompile and investigate.

[SecurityCritical]
[MethodImpl(MethodImplOptions.InternalCall)]
private static extern string[] GetManifestResourceNames(RuntimeAssembly assembly);

However from experiments we found out that the order of returned resources depends on the order they are defined in the *.csproj file.

Special thanks to Grzegorz S. for taking part in our experiments.

NHibernate Internals: Exploring NHibernate Proxy Part 3

Introduction

This is the next post from the quesi-series of notes about NHibernate Proxies.

What is ProxyDummy?

In the first post I introduced generated class for MyProxyImpl class implementing IMyProxy interface. One of the interesting things here is ProxyDummy class the proxy is directly inheriting from:

public class INHibernateProxyProxy : ProxyDummy, INHibernateProxy, IMyProxy, ISerializable, IProxy

NHibernate Internals: Exploring NHibernate Proxy Part 2

Introduction

In the previous post I showed how simple proxy class was generated by proxy factory. Now it is time to find some answers to the questions I asked.

The suspicious name of the proxy class

We have a mapped class called MyProxyImpl and it implements an interface IMyProxy. The implementing proxy class name is INHibernateProxyProxy. This is strange and questionable. Let's investigate this and I will try answer the first question: Why it has such a strange name?

NHibernate Internals: Exploring NHibernate Proxy Part 1

Introduction

This is a first post from series I plan to write about proxy feature in NHibernate. I would treat this as a notes and observation rather than a regular tutorial. I hope that you can find these quasi-posts series useful. I encourage you to make experiments with NHibernate!
The version I'am working with is 3.3.1.4000. The names here or in the next posts will refer to the test case names or types used there.

NHibernate Proxy at a glance

NHibernate provides enabled by default feature called lazy-loading. In a one word: this is a feature that allows to keep a non-loaded referenced entity or collection of entities attached to the entity you are working with and loading them on demand when it is necessary.