Folks,

I have a DataLayer assembly that contains all NHibernate mappings as embedded resources, and all data entity classes.

The assembly is called "DataLayer(.dll)", but the namespace is called "MyCompany.AppName.DataLayer".

My problem is: no matter which combinations of assembly and namespace name I try to use in the <configuration>.AddAssembly() calls, it never works. It appears as if NHibernate strictly assumes that the assembly name (the name of the physical DLL file) and the namespace inside that file are going to be the same (and happily mixes the two inappropriately).

As soon as I rename the namespace to be the same as the file name, everything begins to work....

Why this artificial limitation? It's perfectly legal and usually advisable to have a namespace that is DIFFERENT from the actual assembly name - why can't HHibernate (1.0.1) deal with this??

Thanks!
Marc

It's not a limitation, it just assumes a certain convention. You can still use AddResource and specify the resources manually if you don't follow the convention.

>>You can still use AddResource and specify the
>>resources manually if you don't follow the convention.

Unfortunately, that doesn't seem to be working as expected.

I tried:

Assembly DataLayer = Assembly.Load("DataLayer");
cfg.AddResource("MyCompany.AppName.DataLayer.Employees.hbm.xml", DataLayer);

but I got an error in this case (assembly not found). But according to all I know, you have to specify the RESOURCE NAME, which is <namespace>.<resourcename> and this is what I specified here (yet it seems NHibernate tried to derive the assembly name from the resource name, which fails in this case).

Any ideas?
Marc

No, NH just passes the resource name to Assembly.GetManifestResourceStream unchanged. Your problem is that either Assembly.Load call failed, or the resource name is wrong.

>>No, NH just passes the resource name to
>>Assembly.GetManifestResourceStream unchanged.
>>Your problem is that either Assembly.Load call failed,
>>or the resource name is wrong.

It must have been, yes, sorry 'bout that. Works like a charm now!

Marc