If you configure NHibernate in code rather than using app.config or web.config you should be able to avoid the problem you describe. For example you could use Fluent NHibernate's Fluent Configuration feature to configure NHibernate and thus avoid use of both web.config and hibernate.cfg.xml, which potentially could cause some trouble as well.
I am currently using this approach in a web app, where the data access layer is in a separate assembly and the web assembly has no reference to NHibernate and needs no modification to web.config, nor is a hibernate.cfg.xml file used.
Here is an example of a Fluent configuration:
sessionFactory = Fluently.Configure()
.Mappings(x => x
.FluentMappings.AddFromAssemblyOf<FooMap>()
.ConventionDiscovery.AddFromAssemblyOf<BarConvention>()
)
.Database(MsSqlConfiguration.MsSql2005.ConnectionString(x => x
.Database("YourDbName")
.Server(@".\SQLEXPRESS")
.TrustedConnection())
.ShowSql())
.BuildSessionFactory();
Update:
The same goal should be possible to achieve using only standard NHibernate, by using their programmatic configuration possibilities. Instead of using the web.config or such to configure your database connection etc. you could pass an IDictionary instance to Configuration.SetProperties() when you create your session factory.
Something like this:
Configuration config = new Configuration();
IDictionary properties = new Hashtable();
properties["hibernate.dialect"] = "NHibernate.Dialect.MsSql2005Dialect";
// more properties here ...
config.SetProperties(properties);
Chapter 3 of the docs has some info about this, but it is a bit on the short side.