Got the answer--it turns out that my problem wasn't an NHibernate problem at all, but a SQL CE problem. But, since it affects NHibernate apps that use SQL CE, let me explain what I found. Hopefully, it will help folks with similar questions down the road.
SQL CE is made up of the main System.Data.SqlServerCe.dll and seven helper DLLs--sort of like Snow White and the Seven Dwarves. The odd thing about the seven dwarves is that they never get copied to the application output directory, even if you specify that they should, and they never get removed when you clean a solution. Plus, when you add a reference to System.Data.SqlServerCe.dll to a project, its CopyLocal property defaults to False.
When we compile a .NET application, the compiler copies dependencies from project folders to the application output folder--the output folder of the executable that runs the app. Or, in the case of a unit-test setup, the output folder of the unit test project. Snow White gets copied (if CopyLocal is changed to True), but the seven dwarves don't.
To get the seven dwarves copied to the application output directory, you have to use a post-build event in the executable project. The post-build event triggers a copy command to force the copying. I find it easiest to put all eight files in a separate subfolder and copy everything from there, including Snow White (I leave CopyLocal set to False on the reference).
Here is what my copy command in the post-build event looks like:
copy "$(SolutionDir)SharedLibs\SqlServerCe\*.*" "$(ProjectDir)$(OutDir)"
That gets all of the SQL CE files copied to the application output directory, with the result that NHibernate is able to properly configure itself and create a session factory.
David Veeneman
Foresight Systems
|