NHibernate 3.1 migration problem with Linq

Question

I am facing a issue regarding the migration from NHibernate 2.1.2 + Fluent 1.0 to NHibernate 3.1 + Fluent 1.2 :

Used to work :

 List<Order> orders = session.Linq<Order>()
                .Where(o => o.OrderLines.Any(ol => printStatuses.Contains(ol.PrintStatus)))
                .ToList();

Don't work anymore

 List<Order> orders = session.Query<Order>()
                .Where(o => o.OrderLines.Any(ol => printStatuses.Contains(ol.PrintStatus)))
                .ToList();

We get the following error :

"Could not load type o.OrderLines. Possible cause: the assembly was not loaded or not specified."

OrderLines is a collection property of the class Order, typed IList<OrderLine>

NHibernate seems to not be able to get the fully qualified class name of that collection. Though, looking at the session factory, we can see that collectionRolesByEntityParticipant dictionary contains a key for the class OrderLine with a dictionary value pointing to Order.Orderlines.

Has anyone solved this ?

EDIT :

PS : We use automapping in case you wonder.

Are you sure that this is an unhandled exception? I often get first chance exceptions like "Could not load type x.y" with Linq in NHibernate 3 but they don't prevent the query from working. — cremor
Indeed I am quite surprised, even though I get these exceptions it seems to work fine... I still have some issues we another type of query but that's another matter. Thanks ! — Breakdown

viggity viggity · Accepted Answer · 2012-02-06T16:08:22

Like @cremor mentioned, this likely isn't a problem with nhibernate or your app. I ran into the same issue. If you go to the Exceptions Dialog box (Ctrl+Alt+E) you probably have "throw" checked for all "Common Language Runtime Exceptions". When they are checked, visual studio will break into the debugger everytime an exception is thrown, even if it is handled by a try catch. Normally when you have a dependency on an assembly you don't own/control, you only reference the dll and you don't have a copy of the pdb debugging files. Visual Studio doesn't know to break into the debugger unless it has the pdb files.

TL;DR - Delete the NHibernate.pdb, Iesi.Collections.pdb, Nhibernate.ByteCode.Castle.pdb files and visual studio won't break into the debugger and will keep chugging along.

NHibernate 3.1 migration problem with Linq

1 Answers