Проблема миграции NHibernate 3.1 с Linq

#c# #linq #nhibernate #fluent

#c# #linq #nhibernate #свободно

Вопрос:

Я столкнулся с проблемой, связанной с переходом с NHibernate 2.1.2 Fluent 1.0 на NHibernate 3.1 Fluent 1.2 :

Раньше работал :

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

Больше не работает

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

Мы получаем следующую ошибку :

«Не удалось загрузить тип o.OrderLines. Возможная причина: сборка не была загружена или не указана.»

OrderLines — это свойство коллекции класса Order, введенное IList<Строка порядка>

Похоже, что NHibernate не может получить полное имя класса этой коллекции. Хотя, глядя на фабрику сеансов, мы можем видеть, что словарь collectionRolesByEntityParticipant содержит ключ для OrderLine класса со значением словаря, указывающим на порядок.Строки порядка.

Кто-нибудь решил это?

Редактировать :

PS: На случай, если вам интересно, мы используем автоматическое сопоставление.

1. Вы уверены, что это необработанное исключение? Я часто получаю исключения первого шанса, такие как «Не удалось загрузить тип x.y» с Linq в NHibernate 3, но они не мешают работе запроса.

2. Действительно, я весьма удивлен, даже несмотря на то, что я получаю эти исключения, кажется, что все работает нормально… У меня все еще есть некоторые проблемы с другим типом запросов, но это другой вопрос. Спасибо!

3. Смотрите ответ viggity, это может помочь

Ответ №1:

Как упоминал @cremor, это, скорее всего, не проблема с nhibernate или вашим приложением. Я столкнулся с той же проблемой. Если вы перейдете в диалоговое окно исключений ( Ctrl Alt E ), у вас, вероятно, установлен флажок «выбрасывать» для всех «Исключений среды выполнения Common Language». Когда они будут проверены, visual Studio будет врываться в отладчик каждый раз, когда генерируется исключение, даже если оно обрабатывается с помощью try catch. Обычно, когда у вас есть зависимость от сборки, которой вы не владеете / не управляете, вы ссылаетесь только на dll и у вас нет копии файлов отладки pdb. Visual Studio не знает, как взломать отладчик, если у него нет файлов pdb.

TL; DR — Удалите NHibernate.pdb, Iesi.Коллекции.pdb, Nhibernate.Байт-код.Файлы Castle.pdb и visual studio не будут взломаны в отладчике и будут продолжать работать с пыхтением.

1. Возможно, ваше решение сработало, мы действительно использовали «Исключения Common Language Runtime Exceptions» для устранения другой проблемы. К сожалению, я больше не работаю над проектом, поэтому не могу подтвердить…