Hibernate version:
NHibernate 1.2

Name and version of the database you are using:
MS SQL 2005

My question is regarding the approach we are trying to take for a web app using NHibernate.

From front to back, we have an ASP.NET front-end that calls a web service which in turn calls a data access DLL that has all the objects that we are linking to the database via NHibernate.

The data access DLL that carries all the data objects/mappings works fine. I have an App.config file with the nhibernate configuration data in this DLL. When unit testing this object, no problems.

We tried to use that DLL from the web service encounterd the following error: "The dialect was not set. Set the property hibernate.dialect."

It turned out that we needed to have the nhibernate configuration data in the Web.config of the web service as well as the data access DLL. Once we added the nhibernate configuration data from the DLL's App.config to the web service's Web.config we were able to use data access DLL in the web service no problem.

Is this by design, or are we doing something wrong? It seemed to us when we started that all the nhibernate interaction (including configuration) could exist in the one DLL. Now it appears we will need to carry the configuration data in anything that also is a consumer of the data access DLL.

Unless you hard-code the configuration information into your data access DLL, you are going to have to provide the app.config file.

There are other ways of configuring NHibernate, but basically, if you don't hard-code, then everywhere the data access DLL is used, it is going to need to load those configuration values.

I'm not sure what you're hoping for.

Just one addition: you may be confused because you unit tester (NUnit, I'm guessing) consumed your xxx.dll.config file. However, this is something "special" that NUnit does to make unit testing a little smoother. In general, applications will not consume .dll.configs without being coded to do so. You might notice that VS doesn't even build a config for a .dll from the app.config in the project.

This is by design: the assumption is that any and all components of an application will be configured at the application level, not come "preconfigured" as it were.