Letysite.ru

IT Новости с интернет пространства
0 просмотров
Рейтинг статьи
1 звезда2 звезды3 звезды4 звезды5 звезд
Загрузка...

Ожидалось что модуль содержит манифест сборки

Формат сборки .NET

Ознакомившись с некоторыми преимуществами сборок .NET. давайте более детально рассмотрим, как эти сборки устроены внутри. С точки зрения структуры любая сборка .NET (*.dll или *.ехе) включает в себя следующие элементы:

заголовок файла Windows;

заголовок файла CLR;

дополнительные встроенные ресурсы.

Хотя первые два элемента представляют собой такие блоки данных, на которые обычно можно не обращать внимания, краткого рассмотрения они все-таки заслуживают. Ниже предлагаются краткие описания всех перечисленных элементов.

Заголовок файла Windows

Заголовок файла Windows указывает на тот факт, что сборка может загружаться и использоваться в операционных системах семейства Windows. Кроме того, этот заголовок идентифицирует тип приложения (консольное, приложение с графическим пользовательским интерфейсом или библиотека кода *.dll). Чтобы просмотреть информацию, содержащуюся в заголовке Windows, необходимо открыть сборку .NET в утилите dumpbin.ехе (в окне командной строки Visual Studio 2010) с указанием флага /headers:

Ниже показано, как будет выглядеть информация в заголовке Windows сборки Program.exe:

Теперь, важно уяснить, что большей части программистов, работающей с .NET, никогда не придется беспокоиться о формате встраиваемых в сборку .NET данных заголовков. Если только не требуется разрабатывать новый компилятор для одного из языков .NET (где такая информация действительно важна), можно не вникать в тонкие детали данных заголовков. Однако помните, что эта информация используется «за кулисами», когда Windows загружает двоичный образ в память.

Заголовок файла CLR

Заголовок CLR представляет собой блок данных, который должны обязательно поддерживать все сборки .NET (что они и делают, благодаря компилятору C#) для того, чтобы они могли обслуживаться в CLR-среде. Вкратце, в этом заголовке определяются многочисленные флаги, которые позволяют исполняющей среде разобраться в компоновке управляемого файла. Например, эти флаги указывают, где внутри файла находятся метаданные и ресурсы, как выглядит версия исполняющей среды, на которую ориентировалась данная сборка, каково (необязательное) значение открытого ключа, и т.д. Чтобы просмотреть данные заголовка CLR в сборке .NET, необходимо открыть сборку в утилите dumpbin.exe с указанием флага /clrheader:

Опять-таки, разработчики приложений .NET не должны беспокоиться о тонких деталях заголовков CLR. Главное понимать, что такие данные обязательно содержатся в каждой сборке .NET и применяются исполняющей средой .NET при загрузке образа в память. Теперь рассмотрим информацию, которая является гораздо более полезной при решении повседневных программистских задач.

CIL-код, метаданные типов и манифест сборки

В своей основе любая сборка содержит код на языке CIL, который, представляет собой промежуточный язык, не зависящий ни от платформы, ни от процессора. Во время выполнения внутренний CIL-код «на лету» (посредством JIT-компилятора) компилируется в инструкции, соответствующие требованиям конкретной платформы и процессора. Благодаря этому, сборки .NET в действительности могут выполняться в рамках разнообразных архитектур, устройств и операционных систем.

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

Кроме того, в любой сборке должен обязательно содержаться ассоциируемый с ней манифест (по-другому еще называемый метаданными сборки). В этом манифесте описан каждый входящий в состав сборки модуль, версия сборки, а также любые внешние сборки, на которые ссылается текущая сборка (что отличает сборки от библиотек типов СОМ, в которых не существовало никакой возможности для документирования внешних зависимостей). Как будет показано далее в главе, манифест сборки интенсивно применяется в CLR-среде во время определения места, на которое указывают представляющие внешние сборки ссылки.

Необязательные ресурсы сборки

И, наконец, в любой сборке .NET может также содержаться любое количество вложенных ресурсов, таких как значки приложения, графические файлы, звуковые фрагменты или таблицы строк. На самом деле платформа .NET поддерживает возможность создания даже так называемых подчиненных сборок (satellite assemblies), содержащих только локализованные ресурсы и больше ничего. Эта возможность может быть очень удобной, когда необходимо разделить ресурсы по конкретным культурам (английской, немецкой и т.п.) при построении программного обеспечения, которое предназначено для использования по всему миру.

Однофайловые и многофайловые сборки

С технической точки зрения сборка может состоять из нескольких так называемых модулей (module). Модуль на самом деле представляет собой не более чем просто общий термин, применяемый для обозначения действительного двоичного файла .NET. В большинстве ситуаций, однако, сборка состоит из единственного модуля. В этом случае между (логической) сборкой и лежащим в ее основе (физическим) двоичным файлом существует соответствие типа «один к одному» (откуда и происходит термин «однофайловая сборка»).

В однофайловых сборках все необходимые элементы (заголовки Windows и CIL, метаданные типов, манифест и необходимые ресурсы) размещаются внутри единственного пакета *.ехе или *.dll. На рисунке схематично показано устройство однофайловой сборки:

Многофайловая сборка, с другой стороны, состоит из набора модулей .NET, которые развертываются в виде одной логической единицы и снабжаются одним номером версии. Формально один из этих модулей называется главным модулем и содержит манифест сборки (а также все необходимые CIL-инструкции, метаданные, заголовки и дополнительные ресурсы).

В манифесте главного модуля описаны все остальные связанные модули, от которых зависит его работа. По соглашению второстепенным модулям в многофайловой сборке назначается расширение *.netmodule; обязательным требованием для CLR-среды это, однако, не является. Во второстепенных модулях *.netmodule тоже содержится CIL-код и метаданные типов, а также манифест уровня модуля, в котором перечислены внешние сборки, необходимые данному модулю.

Главное преимущество многофайловых сборок состоит в том, что они предоставляют очень эффективный способ для выполнения загрузки содержимого. Например, предположим, что есть машина, которая ссылается на удаленную многофайловую сборку, состоящую из трех модулей, главный из которых установлен на клиенте. Если клиенту понадобится какой-то тип из второстепенного удаленного модуля *.netmodule, CLR-среда по его требованию начнет немедленно загружать на локальную машину в специальное место, называемое кэшем загрузки (download cache) только соответствующий двоичный файл. В случае, если размер каждого модуля *.netmodule составляет 5 Мбайт, преимущество сразу же станет заметным (по сравнению с загрузкой одного файла размером в 15 Мбайт).

Читать еще:  Сборка 3d принтера своими руками

Другим преимуществом многофайловых сборок является то, что они позволяют создавать модули на различных языках программирования .NET. После компиляции отдельные модули все могут легко «объединяться» в одну логическую сборку с помощью компилятора C# командной строки.

Ожидалось, что модуль будет содержать манифест сборки (hr = 0x80131018)

У меня проблема с моим проектом. В моем проекте была целевая структура 4.5.1, и все было хорошо. Я изменил целевую структуру проекта на 3.5 и получил проблемы.

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

Ошибка при попытке запустить проект. Вы не можете загрузить файл или сборку или одну из своих зависимостей. Ожидалось, что модуль будет содержать манифест сборки. ‘

Когда я перехожу к taget framework v4.5, все работает. Но не тогда, когда целевая структура установлена на v3.5. Я проверил каждую ссылку этого проекта, и все они нацелены на платформу 3.5 или меньше.

Я использовал этот TOOL Logs, который говорит что-то вроде этого:

(. ) Ссылки на результат: hr = 0x80131018. Нет описания. Менеджер загружен из C:WindowsMicrosoft.NETFramework64v2.0.50727mscorwks.dll(. ) ERROR: ошибка при извлечении файла манифеста импорта (hr = 0x80131018). ОШИБКА: Не удалось установить установочный комплект (hr = 0x80131018). Исследование завершено. (. )

Я также пытался очистить и перестроить решение, но не помогло. Но, как я уже сказал, ошибок в списке ошибок нет, сборка завершена успешно. Эта ошибка возникает, когда я пытаюсь запустить проект.

EDIT: Полный список ссылок на проекты:

Трассировка пути fuslogvw:

* Запись в сборке Binder (2016-08-01 @13:42:46) *

Операция завершилась неудачно. Результат привязки: hr = 0x80131018. Нет описания.

Менеджер сборки загружен из: C:WindowsMicrosoft.NETFramework64v2.0.50727mscorwks.dll Запуск под исполняемый файл C:svn_reposszynakaKlasyElemBuild całościKiosk_net35.vshost.exe — Подробный журнал ошибок следующим образом.

=== Информация о состоянии предварительной привязки ===

LOG: Пользователь = Paweł -PCPaweł

LOG: DisplayName = Kiosk_net35 (частично)

LOG: Appbase = file:///C: /svn_repos/szynaka/KlasyElem/Build całości/

LOG: Initial PrivatePath = NULL

LOG: Dynamic Base = NULL LOG: Кэш-база = NULL

LOG: AppName = NULL Вызов сборки: Microsoft.VisualStudio.HostingProcess.Utilities, Version = 12.0.0.0, Culture = neutral, PublicKeyToken = b03f5f7f11d50a3a.

LOG: Это связывание начинается с контекста нагрузки по умолчанию. LOG: Использование файла конфигурации приложения: C:svn_reposszynakaKlasyElemBuild całościKiosk_net35.vshost.exe.Config

LOG: Использование файла конфигурации машины из C:WindowsMicrosoft.NETFramework64v2.0.50727configmachine.config.

LOG: политика не применяется к ссылке в это время (частное, пользовательское, частичное или привязку сборки на основе местоположения).

LOG: попытка загрузки нового файла URL:///C: /svn_repos/szynaka/KlasyElem/Build całości/Kiosk_net35.DLL.

LOG: попытка загрузки нового файла URL:///C: /svn_repos/szynaka/KlasyElem/Build całości/Kiosk_net35/Kiosk_net35.DLL.

LOG: попытка загрузки нового файла URL:///C: /svn_repos/szynaka/KlasyElem/Build całości/Kiosk_net35.EXE.

LOG: сборка была успешной. nУдаление настройки файла: C:svn_reposszynakaKlasyElemBuild całościKiosk_net35.exe LOG: переход в фазу установки запуска от источника.

ERR: Ошибка извлечения манифеста из файла (hr = 0x80131018).

ERR: Не удалось завершить настройку сборки (hr = 0x80131018). Исследование прекращено.

EDIT2: файл манифеста с ildasm.exe:

reference c# .net-assembly .net runtime-error

Ожидалось, что модуль будет содержать манифест сборки (hr = 0x80131018)

У меня проблема с моим проектом. В моем проекте была целевая структура 4.5.1, и все было хорошо. Я изменил целевую структуру проекта на 3.5 и получил проблемы.

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

Ошибка при попытке запустить проект. Вы не можете загрузить файл или сборку или одну из своих зависимостей. Ожидалось, что модуль будет содержать манифест сборки. ‘

Когда я перехожу к taget framework v4.5, все работает. Но не тогда, когда целевая структура установлена на v3.5. Я проверил каждую ссылку этого проекта, и все они нацелены на платформу 3.5 или меньше.

Я использовал этот TOOL Logs, который говорит что-то вроде этого:

(. ) Ссылки на результат: hr = 0x80131018. Нет описания. Менеджер загружен из C:WindowsMicrosoft.NETFramework64v2.0.50727mscorwks.dll(. ) ERROR: ошибка при извлечении файла манифеста импорта (hr = 0x80131018). ОШИБКА: Не удалось установить установочный комплект (hr = 0x80131018). Исследование завершено. (. )

Я также пытался очистить и перестроить решение, но не помогло. Но, как я уже сказал, ошибок в списке ошибок нет, сборка завершена успешно. Эта ошибка возникает, когда я пытаюсь запустить проект.

EDIT: Полный список ссылок на проекты:

Трассировка пути fuslogvw:

* Запись в сборке Binder (2016-08-01 @13:42:46) *

Операция завершилась неудачно. Результат привязки: hr = 0x80131018. Нет описания.

Менеджер сборки загружен из: C:WindowsMicrosoft.NETFramework64v2.0.50727mscorwks.dll Запуск под исполняемый файл C:svn_reposszynakaKlasyElemBuild całościKiosk_net35.vshost.exe — Подробный журнал ошибок следующим образом.

=== Информация о состоянии предварительной привязки ===

LOG: Пользователь = Paweł -PCPaweł

LOG: DisplayName = Kiosk_net35 (частично)

LOG: Appbase = file:///C: /svn_repos/szynaka/KlasyElem/Build całości/

LOG: Initial PrivatePath = NULL

LOG: Dynamic Base = NULL LOG: Кэш-база = NULL

LOG: AppName = NULL Вызов сборки: Microsoft.VisualStudio.HostingProcess.Utilities, Version = 12.0.0.0, Culture = neutral, PublicKeyToken = b03f5f7f11d50a3a.

LOG: Это связывание начинается с контекста нагрузки по умолчанию. LOG: Использование файла конфигурации приложения: C:svn_reposszynakaKlasyElemBuild całościKiosk_net35.vshost.exe.Config

LOG: Использование файла конфигурации машины из C:WindowsMicrosoft.NETFramework64v2.0.50727configmachine.config.

LOG: политика не применяется к ссылке в это время (частное, пользовательское, частичное или привязку сборки на основе местоположения).

LOG: попытка загрузки нового файла URL:///C: /svn_repos/szynaka/KlasyElem/Build całości/Kiosk_net35.DLL.

LOG: попытка загрузки нового файла URL:///C: /svn_repos/szynaka/KlasyElem/Build całości/Kiosk_net35/Kiosk_net35.DLL.

LOG: попытка загрузки нового файла URL:///C: /svn_repos/szynaka/KlasyElem/Build całości/Kiosk_net35.EXE.

LOG: сборка была успешной. nУдаление настройки файла: C:svn_reposszynakaKlasyElemBuild całościKiosk_net35.exe LOG: переход в фазу установки запуска от источника.

ERR: Ошибка извлечения манифеста из файла (hr = 0x80131018).

ERR: Не удалось завершить настройку сборки (hr = 0x80131018). Исследование прекращено.

EDIT2: файл манифеста с ildasm.exe:

reference c# .net-assembly .net runtime-error

Ошибка при попытке запустить проект: ожидается, что модуль будет содержать манифест сборки

Когда я пытаюсь запустить проект, он говорит:

Ошибка при попытке запуска проекта: не удалось загрузить файл или сборку « Project.exe » или одну из ее зависимостей.
Ожидается, что модуль будет содержать манифест сборки.

Когда я запустил exe из папки отладки, я получил эту ошибку:

приложение не может начать правильно (0xc000007b)

Я также переустановил Visual Studio, но он не работает!

Как я могу решить свою проблему?

Ожидается, что модуль будет содержать манифест сборки

Читать еще:  Методы и средства сбора информации

Это проблема загрузки с низким уровнем сборки. CLR имеет файл с правильным именем, но когда он пытается загрузить сборку, он обнаруживает, что файл не содержит надлежащего манифеста. Узел .NET должен содержать манифест, он содержит метаданные, описывающие сборку, перечисление типов в сборке и т. Д.

Если вы не знаете, какой EXE или DLL может быть нарушителем проблем, вы можете использовать утилиту Fuslogvw.exe :

  1. Запустите его из командной строки Visual Studio.
  2. Нажмите кнопку «Настройки» и нажмите переключатель «Логарифмические сбои на диске».
  3. Вернитесь к VS и запустите программу и дождитесь появления исключения.
  4. Вернитесь к Fuslogvw, нажмите кнопку «Обновить» и дважды щелкните добавленную запись.
  5. Он показывает вам файл, который он нашел.

Несколько возможностей, которые в наши дни представляют собой попытку загрузить сборку .NET 4 с EXE, который запросил версию CLR версии 2. Для этого требуется файл app.exe.config, который заставляет использовать CLR 4.

В моем случае я просто изменяю Target Framework (.Net Framework 4) в свойствах проекта. Это решает проблему.

У меня такая же проблема, когда я использую Vs2012 utimate для публикации Asp.net Mvc4, а затем загружаю dll на сервер. Я исправил его, построив код как режим деблокирования, затем загрузив всю dll в папку bin на сервер.

В моем случае он исправляется, просто перейдя к свойствам проекта, а set -> startup object projectname.program и build-> target target -> x86.

я просто разрешаю это по проблеме, перезагружая Систему, а также в свойствах проекта, которые я устанавливаю для нескольких пользователей, а также в опции запуска combo box. Надеюсь, это поможет вам.

0xc000007b – «STATUS_INVALID_IMAGE_FORMAT». Из опыта это указывает на свойства проекта. Несколько вещей стоит проверить:

  • Проверьте, установлены ли все параметры сборки на x86 или x64 в зависимости от вашей системной архитектуры или AnyCPU.
  • Если вы используете DLL, подумайте, были ли они скомпилированы для вашей целевой архитектуры или нет. Если нет, то перекомпилируйте их соответственно или получите их в правильной версии, откуда бы вы их не получили.
  • Наконец, проверьте, имеют ли ваша assembly проекта и загруженные сборки разные имена. Это похоже на то, что дела идут бум.

Определение манифеста сборки расположены не соответствует ссылке на сборку

Я пытаюсь запустить некоторые модульные тесты в приложении C# Windows Forms (Visual Studio 2005), и я получаю следующую ошибку:

Система.ИО.FileLoadException: не удалось загрузить файл или сборку «утилита, версия=1.2.0.200, культура=нейтральная, PublicKeyToken=764d581291d764f7» или одну из ее зависимостей. Определение манифеста сборки расположены не соответствует ссылке на сборку. (Исключение из HRESULT: 0x80131040)**

на x.Фу.Foo2 (строка groupname) в Foo.cs: строка 123

на x.Фу.Unit-тестов.FooTests.TestFoo () в Футестах.cs: line 98**

Система.ИО.FileLoadException: не удалось загрузить файл или сборку «утилита, версия=1.2.0.203, культура=нейтральная, PublicKeyToken=764d581291d764f7» или одну из ее зависимостей. Определение манифеста сборки расположены не соответствует ссылке на сборку. (Исключение из HRESULT: 0x80131040)

Я смотрю в моем ссылки, и у меня есть только ссылка на Utility version 1.2.0.203 (другой старый).

любые предложения о том, как я понимаю, что пытается ссылаться на эту старую версию этого файла DLL?

кроме того, я не думаю, что у меня даже есть эта старая сборка на моем жестком диске. Есть ли какой-либо инструмент для поиска этой старой версионной сборки?

30 ответов

загрузчик сборок .NET не может найти 1.2.0.203, но нашел 1.2.0.200. Эта сборка не соответствует тому, что было предложено, и поэтому вы получаете эту ошибку. Проще говоря, он не может найти сборку, на которую была сделана ссылка. Убедитесь, что он может найти правильную сборку, поместив ее в GAC или в путь приложения. Также см. http://blogs.msdn.com/junfeng/archive/2004/03/25/95826.aspx.

вы можете сделать несколько вещей, чтобы устранить эту проблему. Во-первых, используйте Windows File search для поиска жесткого диска для сборки (.файл DLL.) После того, как у вас есть список результатов, сделайте вид->выберите детали. а затем проверьте «версия файла». Это отобразит номер версии в списке результатов, чтобы вы могли видеть, откуда может исходить старая версия.

кроме того, как сказал Ларс, проверьте свой GAC, чтобы увидеть, какая версия указана там. эта статья Microsoft государств сборки, найденные в GAC, не копируются локально во время сборки, поэтому вам может потребоваться удалить старую версию перед выполнением перестроения all. (См. мой ответ этот вопрос для заметок о создании пакетного файла, чтобы сделать это для вас)

Если вы все еще не можете понять, откуда берется старая версия, вы можете использовать fuslogvw.exe-приложение, которое поставляется с Visual Studio для получения дополнительной информации о сбоях привязки. У Microsoft есть сведения об этом средстве здесь. Обратите внимание, что вам нужно включить ведение журнала, установив HKEY_LOCAL_MACHINESOFTWAREMicrosoftFusionEnableLog ключ реестра 1.

Я просто столкнулся с этой проблемой сам, и я обнаружил, что проблема была чем-то отличным от того, с чем столкнулись другие.

У меня было две библиотеки DLL, на которые ссылался мой основной проект: CompanyClasses.dll и CompanyControls.файл DLL. Я получал ошибку времени выполнения, говоря:

не удалось загрузить файл или сборку ‘CompanyClasses, Версия=1.4.1.0, Культура=нейтральный, PublicKeyToken=045746ba8544160c ‘ или одна из его зависимостей. В расположенном собрания манифест определение не соответствует ссылке на сборку

проблема в том, что у меня не было CompanyClasses.dll-файлы в моей системе с номером версии 1.4.1. Ни в GAC, ни в папках приложений. нигде. Я обыскал весь жесткий диск. Все CompanyClasses.dll файлы у меня были 1.4.2.

реальная проблема, я обнаружил, что CompanyControls.dll ссылается на версию 1.4.1 CompanyClasses.файл DLL. Я только что перекомпилировал CompanyControls.файл DLL (после того, как он ссылался на CompanyClasses.dll файлы 1.4.2) и эта ошибка ушла для меня.

следующее перенаправляет любую версию сборки на версию 3.1.0.0. У нас есть скрипт, который всегда будет обновлять эту ссылку в приложении.config, поэтому нам больше не придется иметь дело с этой проблемой.

через отражение вы можете получить сборку publicKeyToken и сгенерировать этот блок из.сам файл dll.

обратите внимание, что без атрибута пространства имен XML (xmlns) это не будет работать.

Если вы используете Visual Studio, попробуйте «чистое решение», а затем перестройте проект.

Читать еще:  Лучшие сборки драйверов

Если вы не заботитесь о версии, и вы просто хотите, чтобы ваше приложение работало, щелкните правой кнопкой мыши ссылку и установите «конкретную версию» в false. Другие решения не работают для меня.

Я просто столкнулся с этой проблемой, и проблема была в том, что у меня была старая копия .dll в каталоге отладки моего приложения. Возможно, вы захотите также проверить там (вместо GAC), чтобы увидеть, видите ли вы его.

я добавил пакет NuGet, только чтобы понять, что часть черного ящика моего приложения ссылается на более старую версию библиотеки.

Я удалил пакет и сослался на статический DLL-файл старой версии, но в интернете.файл конфигурации никогда не обновлялся из:

к чему он должен был вернуться, когда я удалил пакет:

в моем случае это была старая версия DLL в C:WINDOWSMicrosoft.NETFramework

временный ASP.NET файлы каталог. Вы можете удалить или заменить старую версию, или вы можете удалить и добавить обратно ссылку на DLL в вашем проекте. В принципе, в любом случае будет создан новый указатель на временный ASP.NET файлы.

в моем случае эта ошибка произошла во время выполнения ASP.NET применение. Решение было:

  1. удалить obj и bin папки в папке проекта

Clean не работал, rebuild не работал, все ссылки были в порядке, но он не писал одну из библиотек. После удаления этих каталогов, все работало отлично.

для нас, проблема была вызвана чем-то еще. Файл лицензии для компонентов DevExpress включал две строки, одну для старой версии компонентов, которая не была установлена на данном компьютере. Удаление старой версии из файла лицензии решило проблему.

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

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

вам нужно добавить правильный токен открытого ключа (вы можете получить его с помощью SN-T в dll), чтобы устранить ошибку. Надеюсь, это поможет.

моя ситуация была очень похожа на сообщение Натана Бедфорда, но с небольшим поворотом. Мой проект также ссылался на измененную dll двумя способами. 1) напрямую и 2) косвенно, ссылаясь на компонент (библиотеку классов), который сам имел ссылку на измененную dll. Теперь мой проект Visual studio для компонента (2) ссылается на правильную версию измененной dll. Однако номер версии самого compnent не был изменен. И в результате установка новой версии project не удалось заменить этот компонент на клиентском компьютере.

конечный результат: прямая ссылка(1) и косвенная Ссылка (2) указывали на разные версии измененной dll на клиентском компьютере. На моей dev-машине он работал нормально.

разрешение: удалить приложение; удалить все библиотеки DLL из папки приложения; переустановить.В моем случае все просто.

Я позволю кому-то извлечь выгоду из моей тупости сдвига. У меня есть некоторые зависимости от совершенно отдельного приложения (назовем это App1). Dll из этого App1 втягиваются в мое новое приложение (App2). Каждый раз, когда я делаю обновления в APP1, я должен создать новые dll и скопировать их в App2. Что ж. . .Я устал от копирования и вставки между 2 различными версиями App1, поэтому я просто добавил префикс «NEW_» в dll.

хорошо. . . Я предполагаю, что процесс сборки сканирует папка /bin и когда она соответствует чему-то неправильно, она блюет с тем же сообщением об ошибке, как указано выше. Я удалил свои версии «new_», и он построил просто денди.

моей проблемой было копирование исходного кода на новую машину без вытягивания какой-либо из ссылочных сборок.

ничего, что я сделал, исправил ошибку, поэтому в спешке я удалил каталог BIN вообще. Перестроил мой исходный код, и с тех пор он работал.

Я хотел бы просто добавить, что я создавал базовый ASP.NET проект MVC 4 и добавлен DotNetOpenAuth.AspNet через NuGet. Это привело к той же ошибке после того, как я ссылался на несоответствующий DLL-файл для Microsoft.Сеть.страницы.Протокол OAuth.

чтобы исправить это, я сделал Update-Package и очистил решение для полного восстановления.

это сработало для меня и является своего рода ленивым способом, но время-деньги: — P

Я получил эту ошибку при создании Службы сборки Team Foundation Server. Оказалось, что у меня было несколько проектов в моем решении, используя разные версии одной и той же библиотеки, добавленной с NuGet. Я удалил все старые версии с NuGet и добавил новую в качестве ссылки для всех.

Team Foundation Server помещает все DLL-файлы в один каталог, и, конечно, может быть только один DLL-файл с определенным именем.

Я просто нашел еще одну причину, почему получить эту ошибку. Я очистил свой GAC от всех версий определенной библиотеки и построил свой проект со ссылкой на конкретную версию, развернутую вместе с исполняемым файлом. Когда я запускаю проект, я получил это исключение для поиска более новой версии библиотеки.

причина издатель политики. Когда я удалил версии библиотеки из GAC, я забыл удалить сборки политики издателя, поэтому вместо использования моего локально развернутая сборка загрузчик сборок нашел политику издателя в GAC, которая сказала ему искать более новую версию.

для меня конфигурация покрытия кода в » Local.testtesttings «файл» вызвал » проблему. Я забыл обновить файлы, на которые там ссылались.

Мои приложения.config содержит

для npgsql. Как-то на машине пользователя, приложение.исполняемый.конфиг пропал. Я не уверен, что это был глупый пользователь, сбой установщика или отключенный антивирус. Замена файла решила проблему.

очистить и перестроить решение может не заменить все dll из выходного каталога.

Я предлагаю попробовать переименовать папку из «bin» в «oldbin» или «obj»в » oldobj»

а затем попробуйте снова построить свой silution.

incase, если вы используете сторонние dll-файлы, которые вам нужно будет скопировать во вновь созданную папку» bin «или» obj » после успешной сборки.

надеюсь, это сработает для вас.

вручную удаление старой сборки из папки, а затем добавление ссылки на новые сборки может помочь.

Ссылка на основную публикацию
Adblock
detector