Печально известная ошибка привязки сборки
Мне действительно нужна помощь в этом, потому что я потерял надежды исправить проблему.
Я использую 64-битные библиотеки Office Communications Server. В проекте я использую 3 библиотеки: Microsoft.Rtc.Collaboration.dll, Microsoft.Rtc.Internal.Media.dll и SIPEPS.dll. Я не уверен насчет Microsoft.Rtc.Collaboration, но Internal.Media и SIPEPS - оба x64. В списке сборок GAC Rtc.Collaboration показывает MSIL под процессорной архитектурой, а остальные показывают AMD64.
Мой проект без ошибок компилируется с этими ссылками, но во время выполнения я получаю сообщение об ошибке:
Не удалось загрузить файл или сборку "Microsoft.Rtc.Internal.Media" или одну из ее зависимостей. Была предпринята попытка загрузить программу с неверным форматом.
Я попытался скомпилировать проект с установленным CPU на Any CPU, но ничего не изменилось. И с настройками под x64 и x86 я получаю эту ошибку.
Любая помощь приветствуется.
ОБНОВЛЕНИЕ: Ниже приведен журнал привязки сборки.
=== Pre-bind state information ===
LOG: User = CONTOSO\elodie
LOG: DisplayName = Microsoft.Rtc.Internal.Media
(Partial)
WRN: Partial binding information was supplied for an assembly:
WRN: Assembly Name: Microsoft.Rtc.Internal.Media | Domain ID: 9
WRN: A partial bind occurs when only part of the assembly display name is provided.
WRN: This might result in the binder loading an incorrect assembly.
WRN: It is recommended to provide a fully specified textual identity for the assembly,
WRN: that consists of the simple name, version, culture, and public key token.
WRN: See whitepaper http://go.microsoft.com/fwlink/?LinkId=109270 for more information and common solutions to this issue.
LOG: Appbase = file:///C:/Users/elodie/Documents/Visual Studio 2010/Projects/TFS/proto/Main/Source/WebBot.Web/
LOG: Initial PrivatePath = C:\Users\elodie\Documents\Visual Studio 2010\Projects\TFS\proto\Main\Source\WebBot.Web\bin
Calling assembly : (Unknown).
===
LOG: This bind starts in default load context.
LOG: Using application configuration file: C:\Users\elodie\Documents\Visual Studio 2010\Projects\TFS\proto\Main\Source\WebBot.Web\web.config
LOG: Using host configuration file:
LOG: Using machine configuration file from C:\Windows\Microsoft.NET\Framework\v4.0.30319\config\machine.config.
LOG: Policy not being applied to reference at this time (private, custom, partial, or location-based assembly bind).
LOG: Attempting download of new URL file:///C:/Windows/Microsoft.NET/Framework/v4.0.30319/Temporary ASP.NET Files/root/e3d82f59/764fa8c3/Microsoft.Rtc.Internal.Media.DLL.
LOG: Attempting download of new URL file:///C:/Windows/Microsoft.NET/Framework/v4.0.30319/Temporary ASP.NET Files/root/e3d82f59/764fa8c3/Microsoft.Rtc.Internal.Media/Microsoft.Rtc.Internal.Media.DLL.
LOG: Attempting download of new URL file:///C:/Users/elodie/Documents/Visual Studio 2010/Projects/TFS/proto/Main/Source/WebBot.Web/bin/Microsoft.Rtc.Internal.Media.DLL.
ERR: Failed to complete setup of assembly (hr = 0x8007000b). Probing terminated.
11 ответов
Заменили 64-битные версии всех трех библиотек на 32-битные версии, очистили папку временных файлов ASP.NET и снова скомпилировали. Сейчас работает без проблем. Спасибо за помощь.
В моем случае я получил эту проблему, потому что я запускал веб-проект, скомпилированный для x64, используя IISExpress. Я исправил проблему, проверив следующие настройки в Visual Studio:
Инструменты | Варианты | Проекты и решения | Веб-проекты | Используйте 64-битную версию IIS Express
Надеюсь, что это поможет кому-то еще с этим же сценарием и проблемой
У меня была эта проблема с ASP.NET IIS, и после всех попыток я включил 32-разрядную версию для своего пула приложений и перезапустил пулы приложений. Тогда это сработало.
В диспетчере IIS7: Пулы приложений -> DefaultAppPool -> Расширенные настройки -> Установите для "Включить 32-разрядные приложения" значение true.
Также убедитесь, что выбрана правильная версия.Net.
Я также установил для ISAPI 64bit значение в разделе "Ограничения ISAPI и CGI", но я не уверен, помогло ли это.
Попробуйте установить Copy Local в обозревателе решений для этих сборок и убедитесь, что они помещаются в папку, указанную в журнале привязок.
Кроме того, они, вероятно, были построены с использованием V2 CLR. Если это так, вам нужно включить привязку в смешанном режиме, добавив это в конфигурацию веб-приложения.
<configuration>
<startup useLegacyV2RuntimeActivationPolicy="true">
<supportedRuntime version="v4.0"/>
</startup>
</configuration>
Чтобы решить эту проблему, я убедился, что все мои проекты использовали одну и ту же версию, выполнив следующую команду и проверив результаты:
update-package Newtonsoft.Json -reinstall
И, наконец, я удалил следующее из моего web.config:
<dependentAssembly>
<assemblyIdentity name="Newtonsoft.Json" publicKeyToken="30ad4fe6b2a6aeed" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-6.0.0.0" newVersion="6.0.0.0" />
</dependentAssembly>
Я знаю, что это старый вопрос, но все еще кажется популярным результатом при поиске решения относительно частичной ошибки привязки в Visual Studio. У меня была очень похожая проблема с оригинальным постером, но с EntityFramework.dll и Visual studio 2015 (проект.ASP Web Forms), однако, решение, которое я нашел, относится к широкой проблеме. Поскольку я не нашел ответов, похожих на мое решение, я подумал, что было бы полезно поделиться тем, что я нашел, и я надеюсь, что это кому-то поможет.
В моем файле web.config я изображаю пользователя домена, который является служебной учетной записью. Эта служебная учетная запись не имела доступа к моей папке "Временные файлы", поэтому при отладке она не смогла скопировать dll-файлы и, следовательно, не смогла их загрузить.
То, что в конечном итоге предупредило нас, собиралось и физически просматривало временную папку, упомянутую в сообщении об ошибке. В исходном вопросе выше вы заметите строки "Попытка загрузки нового файла URL:///C:/Windows/Microsoft.NET/Framework/v4.0.30319/Tevent ASP.NET Files..." Когда я посмотрел в этой папке моих DLL там не было.
Решение для меня заключалось в следующем: поскольку я использовал 64-битную среду и олицетворял учетную запись домена, я добавил пользователя учетной записи службы домена в свой локальный C:/Windows/Microsoft.NET/Framework64/v4.0.30319/Tevent ASP.NET Files папка с доступом для записи (и изменения - для большей степени).
Итог - убедитесь, что ваша папка временных файлов предоставляет права на запись пользователю, под которым запущено ваше приложение.
Это старый вопрос, но он все еще был лучшим результатом, когда у меня была такая же проблема сегодня. Я переключил компиляцию моего проекта в Visual Studio на x64 вместо "Все процессоры" (это на 64-битной машине). Согласно другим ответам, есть два способа исправить это - либо изменить все на 32-битные, либо все на 64-битные. В этом случае мне нужно было 64-битное.
Ответ KabanaSoft отлично сработал для меня. Все еще корректно с Visual Studio 15.6.6.
Я получал сообщение об ошибке при попытке запустить веб-приложение из Visual Studio, но в моем случае ответ был прост. Когда я внимательно прочитал исключение, я увидел, что рассматриваемая сборка больше не использовалась приложением, а копия все еще находилась в папке bin. После удаления нарушившей сборки ошибка исчезла.
В моем случае я просмотрел свой сайт и заменил название сайта новым именем. Я случайно заменил "PreviousWebSiteName" на "NewWebSiteName" в Web.config, где указывалось имя сборки.
<pages enableSessionState="false" enableViewStateMac="true" enableEventValidation="true" controlRenderingCompatibilityVersion="4.0" clientIDMode="AutoID">
<controls>
<add assembly="NewWebSiteName" namespace="App_Code.Controls" tagPrefix="blog" />
</controls>
</pages>
Сайт все еще создавал сборку со старым именем - я только намеревался изменить имя сайта там, где оно появлялось на страницах сайта; Мне не нужно ничего менять внутри. Восстановление записи Web.config в том виде, в каком она была до изменения имени (в результате чего запись, соответствующая имени встроенной сборки), устранила ошибку для меня.
В моем случае у меня была какая-то хрень в моем файле web.config, в частности, полукомментированный httpHandler, из-за которого моя проблема с привязкой исчезла.
Этот ответ также помогает, если в вашем решении есть только один или несколько проектов, для которых требуется 32-битный IIS:
Переопределить параметр iis 64 для каждого проекта
При этом вы можете оставить параметр в веб-проектах как есть. (см. ответ KabanaSoft)