Hi,

there is a risk of potential trouble for new users of NHibernate-1.1 :
In some cases it might be advantageous using SIMULTANESLY
multiple of the possible ways to specify configuration parameters:
a1) as entries in App.config
a2) as entries in hibernate.cfg.xml
b) by adding name-value-entries into cfg.Properties
where [Configuration cfg = new Configuration;]

The documentation "Chapter 2. ISessionFactory Configuration"
proposes using the statement:
"cfg.Properties = props;" to include the programmatically addded configuration properties.
BUT this statement dicards all configuration property specifications previously collected from file App.config!
The docu gives no hint about that!

Correct is the call:
"cfg.addProperties(props)".
This method merges both sets of configuration properties.
Entries with the same name are overriden by "props".

The implementation in class Configuration is:

public Configuration AddProperties( IDictionary properties )
{
foreach( DictionaryEntry de in properties )
{
this.properties.Add( de.Key, de.Value );
}
return this;
}


An cautious programmer might ask:
>> But what happened if cfg.properties was "null"? <<
(Which is not the case due to the call of "Reset()" in the only constructor of Configuration.)
Or: >> Is it garanteed, that cfg.addProperties(props) will always work (even if cfg.Properties might be null some day [who knows what happens in the future] ) <<


My fail-safe work-around for this possibility is :

class HibernateStarter { // ...
protected static void mergeConfigurationProperties(Configuration config, IDictionary properties)
{
if (config.Properties == null)
config.Properties = properties;
else
config.AddProperties(properties);
}

Btw.
Is there a mechanismus in C# to specify that a variable has always a non-null value (after the constructor has finished its work for the surrounding object)?
The compiler could then prove, that this invariant is true.

Another issue:
Is it true, that "hibernate.cfg.xml" is not read when an App.config file (renamed according to the assembly name) is found?
What were the reasons for this decision?

My proposal is to merge the configuration property specification sets of
1) App.config AND
2) hibernate.cfg.xml

Regards,
Michael