Если вы сконфигурируете NHibernate в коде, а не в app.config или web.config, вы сможете избежать описанной проблемы. Например, вы можете использовать функцию Fluent NHibernate Fluent Configuration для настройки NHibernate и, таким образом, избежать использования как web.config, так и hibernate.cfg.xml, что потенциально может также вызвать некоторые проблемы.
В настоящее время я использую этот подход в веб-приложении, где слой доступа к данным находится в отдельной сборке, а веб-сборка не имеет ссылки на NHibernate и не нуждается в модификации web.config, как и hibernate.cfg.xml. файл используется.
Вот пример конфигурации Fluent:
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();
Обновление:
Этой же цели можно достичь, используя только стандартный NHibernate, используя возможности их программной конфигурации. Вместо того чтобы использовать web.config или тому подобное для настройки соединения с базой данных и т. Д., Вы можете передать экземпляр IDictionary в Configuration.SetProperties () при создании фабрики сеансов.
Примерно так:
Configuration config = new Configuration();
IDictionary properties = new Hashtable();
properties["hibernate.dialect"] = "NHibernate.Dialect.MsSql2005Dialect";
// more properties here ...
config.SetProperties(properties);
Глава 3 документации имеет некоторую информацию об этом, но это немного о короткой стороне.