Updated NHibernate and FNH Libraries - Now Get Missing Permanent Exceptions

Question

I am trying to upgrade my FNH Automapping project to the latest versions of NHibernate and Fluent NHibernate (NH 3.2 and FNH 1.3), but now I get a “no persister” exception in the derived class (although the base class still seems to be saved properly).

This derived Automapped class is excellent with old dlls (FNH 1.0, NH 2.1.2). I have not changed my display logic or these classes in any way.

I updated my project by simply copying the new dlls over the old ones and deleting links to the dlls that are no longer needed (for example, Antlr 3, Castle) with the new dlls.

The exact versions I'm using are:

NHibernate 3.2.0.4000
FluentNHibernate 1.3.0.0
System.Data.SQLite 1.0.76.0
VS 2008 9.0.30729.1 SP
Windows XP SP3 (32 bit)

Display code that works with old dlls, but not with new ones:

return AutoMap.Assemblies(_assemblies) // Don't map the abstract base class .IgnoreBase<OfeEntity>() // Only map subclasses of OfeEntity .Where(t => t.IsSubclassOf(typeof(OfeEntity))) .Conventions.Add( // Do cascading saves on all entities so lists will be // automatically saved DefaultCascade.All(), // Turn on lazy loading, so will only read data that is actually // displayed DefaultLazy.Always() ); 

Edit:

After enabling FNH Diagnostics, I see that FNH does not create a table for my derived class with new dlls.

In addition, one thing I noticed is that a class that is not persistent is subclassed by two levels. That is, I have the following classes:

 public abstract class OfeEntity public class OfeMeasurementBase : OfeEntity public class OfeDlsMeasurement : OfeMeasurementBase 

OfeDlsMeasurement is a class that is not persisted. OfeMeasurementBase, as well as several other classes that inherit OfeEntity, are stored properly.

There was no problem with this in older versions - perhaps new versions have an error when there is more than one level of inheritance?

Answer 1

I transferred our project from some old (F) NH to the latest NH 3.2. I suspect that it now uses different key field names in collections and the like, because I need to specify the exact column names when using an existing database.

In addition, I suggest restoring Fluent NHibernate from sources with NHibernate 3.2 to make sure everything is in place.

Answer 2

Article How to upgrade your applications to NHibernate 3.2 using Fluent NHibernate 1.2 can be useful. I myself used it to update the project, and it worked.