Problema de migration do NHibernate 3.1 com o Linq

Estou enfrentando um problema relacionado à migration do NHibernate 2.1.2 + Fluent 1.0 para o NHibernate 3.1 + Fluent 1.2:

Usado para trabalhar :

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

Não trabalhe mais

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

Nós recebemos o seguinte erro:

“Não foi possível carregar o tipo o.OrderLines . Possível causa: o assembly não foi carregado ou não foi especificado.”

OrderLines é uma propriedade de coleção da class Order , digitada IList

O NHibernate parece não conseguir obter o nome completo da class dessa coleção. No entanto, olhando para a fábrica de session, podemos ver que o dictionary collectionRolesByEntityParticipant contém uma chave para a class OrderLine com um valor de dictionary apontando para Order.Orderlines .

Alguém já resolveu isso?

EDITAR:

PS: Usamos automapping no caso de você se perguntar.

Como @cremor mencionou, isso provavelmente não é um problema com o nhibernate ou seu aplicativo. Eu tive o mesmo problema. Se você for para a checkbox de diálogo Exceções ( Ctrl+Alt+E ), provavelmente terá “jogar” marcada para todas as “Exceções de Tempo de Execução de Idioma Comum”. Quando eles são verificados, o visual studio irá invadir o depurador toda vez que uma exceção for lançada, mesmo que seja manipulada por um try catch. Normalmente, quando você tem uma dependência em uma assembly que não possui / controla, você apenas faz referência à dll e não possui uma cópia dos arquivos de debugging do pdb. O Visual Studio não sabe invadir o depurador, a menos que tenha os arquivos pdb.

TL; DR – Exclua os arquivos NHibernate.pdb, Iesi.Collections.pdb, Nhibernate.ByteCode.Castle.pdb e o visual studio não entrará no depurador e continuará avançando.