Не удалось загрузить файл или сборку в NHibernate

Ответ 1

Эти файлы должны находиться в том же каталоге, что и указанный файл, NHibernate.dll:

• Antlr3.Runtime.dll
• Iesi.Collections.dll
• log4net.dll
• Castle.Core.dll
• Castle.DynamicProxy2.dll

Также вы должны добавить ссылку или скопировать ее тоже:

• NHibernate.ByteCode.Castle.dll

Ответ 2

Я предполагаю, что вы недавно обновили NHibernate до 2.1?

Если это так, я думаю, у вас есть разные проекты, ссылающиеся на разные версии NHibernate.

Это случилось со мной и сложнее отследить, чем вы могли подумать.

Это шаги, которые я предпринял для его решения:

• Удалить все файлы во всех каталогах bin в ваших проектах. Обычно Clean Solution хорошо подходит для этого, но это не так, вам может понадобиться сделать это с помощью командной строки или вручную.
• Отредактируйте все ваши файлы .csproj. Отредактируйте их либо текстовым редактором, либо выполните проект "Разгрузка", затем отредактируйте файл .csproj.
• Убедитесь, что ВСЕ ваши узлы HintPath указывают на ту же (новую) версию DLL

Это, надеюсь, прояснит эту проблему для вас.

Ответ 3

У меня тоже была эта проблема.

Для меня проблема заключалась в том, что FluentNHibernate ожидал другую версию NHibernate (2.1.0.4000), чем я предполагал включить в проект (2.1.2.4000). Я наткнулся на это, отдельно загружая последние версии каждой библиотеки.

Чтобы устранить проблему, я изменил ссылку на NHibernate, чтобы указать на более старую версию NHibernate, которая поставляется с RTM FluenNHibernate 1.0 (2.1.0.4000).

Еще одно решение может заключаться в том, чтобы явно установить привязки к сборке из файла app.config.

Ответ 4

Как будущая ссылка: Если вы столкнулись с теми же проблемами Рэнди Клингельберге (проблемы зависимости между NHibernate и FluentNHibernate или любой другой зависимой библиотекой), вы можете указать перенаправление для сборок, которые предназначено для старой версии. Это не позволяет перекомпилировать зависимую сборку.

<runtime>
  <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
    <dependentAssembly>
      <assemblyIdentity name="NHibernate" publicKeyToken="aa95f207798dfdb4" />
      <bindingRedirect oldVersion="3.0.0.3001" newVersion="3.0.0.4000" />
    </dependentAssembly>
  </assemblyBinding>
</runtime>

Этот код перенаправляет запросы для старой версии (3.0.0.3001 в моем случае) на тот, который фактически используется (3.0.0.4000). PublicKeyToken включен в сообщение об ошибке.

Ответ 5

Недавно я обновил наш проект с 1.0 RTM-версией FluentNHibernate, в которой требовались последние бит NHibernate. Это привело к той же проблеме, с которой вы сталкиваетесь.

Наша структура проекта была примерно такой:

Repository root
    Solution
        Web
            References
                DataAccess
        ... other projects/layers ...
        DataAccess
            References
                ..\ReferenceAssemblies\NHibernate.dll
                ..\ReferenceAssemblies\FluentNHibernate.dll
    ReferenceAssemblies

(Все внешние DLL находятся в каталоге ReferenceAssemblies.)

Моя первая попытка решить эту проблему была путем добавления ссылки на NHibernate.ByteCode.Castle.dll в проект DataAccess. Это сработало... но только в разработке...

Когда я опубликовал веб-приложение на нашем клиентском тестовом сервере (что происходит автоматически с помощью TeamCity и script содержащий вызов aspnet_compiler.exe), NHibernate.ByteCode.Castle.dll нигде не было найдено.

Я не уверен, почему это происходит, но я подозреваю, что это имеет какое-то отношение к тому факту, что никакой код в нашем приложении фактически не вызывает код в этой конкретной DLL. Кроме того, там (исправьте меня, если я ошибаюсь) никакая жесткосвязанная ссылка из NHibernate.dll в NHibernate.ByteCode.Castle, поэтому где-то по этой ссылке игнорируется (предположительно неиспользуемая) dll.

Вторая (и успешная) попытка заключалась в том, чтобы добавить ссылку на отсутствующую dll прямо в веб-проект. Теперь я могу удалить ссылку, которую я добавил с первой попытки, без каких-либо проблем.

(Я не очень люблю иметь такую ​​ссылку в этом конкретном проекте, но эй!): -)

Ответ 6

В моем случае "Clean Solution", а затем "Rebuild Solution" решила проблему.

Ответ 7

Вероятно, у вас есть код, ссылающийся на две разные версии DLL NHibernate. NHibernate.dll, который вы загружаете с помощью NHibernate, скорее всего, отличается от той, которую вы загружаете, скажем, Castle ActiveRecord. Постарайтесь придерживаться только версии DLL NHibernate, которая поставляется с NHibernate.ByteCode.Castle. И убедитесь, что у вас нет NHibernate DLL (любой версии) в вашем GAC (по крайней мере, пока вы не решите эту проблему).

Ответ 8

У меня возникла эта проблема после обновления NHibernate до 3.0 и Spring до ночной сборки, в которой использовался NH 3.0. Проблема заключалась в том, что Spring.Data.NHibernate30.dll ссылался на более старую версию NHibernate.dll(v 3.0.0.2002), а у меня был v 3.0.0.4000.

Моим решением было открыть исходный проект Spring.Data.NHibernate30, удалить ссылки на более раннюю версию NHibernate, добавить ссылку на версию 3.0.0.4000, перестроить и теперь в моем проекте добавить ссылку на эту (новую) версию Spring.Data.NHibernate30.dll.

Ответ 9

Я только что это случилось со мной - в моем случае это был мой первый опыт NHibernate (и Fluent NHibernate). Я выполнил большую часть моего приложения в сборке .dll, на которое ссылается отдельная исполняемая сборка. Исполняемый файл, который не имел ссылок на NHibernate напрямую, давал мне ошибку.

Я использую NuGet для вывода Fluent NHibernate, поэтому я добавил ссылку Fluent NHibernate на исполняемые сборки. Не чувствует себя супер чистым, но он получает зависимости в .bin-папке и устраняет ошибку. (смешно, что это не так (кажется?) происходит с другими библиотеками, такими как NLog)

Ответ 10

Я столкнулся с той же проблемой. Я очистил "Временные файлы Интернета", и этот вопрос исчез.

Ответ 11

NHibernate имеет несколько других сборок, кроме nhibernate.dll. У вас есть все (в том же выпуске)?

Ответ 12

Вам следует ссылаться на зависимые сборки (я думаю, это "NHibernate.ByteCode.Castle" ) и установить для атрибута "copy local" значение true.

Ответ 13

В вашем решении могут быть разные проекты. Этот проект может ссылаться на разные версии NHibernate.dll. Проверяет версии во всех проектах и ​​восстанавливает проект

Ответ 14

Похоже, что dll NHibernate не копируется в каталог bin вашего приложения. Убедитесь, что он указан и существует в каталоге bin.