Подтвердить что ты не робот

Ошибочная ошибка связывания сборки

Мне действительно нужна помощь в этом, потому что я потерял свои надежды исправить проблему.

Я использую 64-битные библиотеки Office Communications Server. В проекте используются три библиотеки DLL, 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 я получаю эту ошибку.

Любая помощь приветствуется.

UPDATE: Ниже представлен журнал привязки сборки.

=== 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.
4b9b3361

Ответ 1

Заменил 64-битные версии всех трех библиотек DLL на свои 32-разрядные версии, очистил папку Temporary ASP.NET и скомпилировал ее снова. Теперь работает без проблем. Спасибо за помощь.

Ответ 2

У меня была эта проблема с ASP.NET IIS, и после всех попыток я включил 32-битный для моего пула приложений и перезапустил пулы приложений. Тогда это сработало.

В диспетчере IIS7: Пулы приложений → DefaultAppPool → Дополнительные параметры → Установите для параметра "Включить 32-разрядные приложения" значение true.

Также убедитесь, что выбрана правильная версия .Net.

Я также установил 64-битный ISAPI для разрешения "Ограничения ISAPI и CGI", но я не уверен, помогло ли это.

Ответ 3

В моем случае я получил эту проблему, потому что я запускал веб-проект, скомпилированный для x64 с помощью IISExpress. Я исправил проблему, установив в Visual Studio следующий параметр:

Инструменты | Варианты | Проекты и решения | Веб-проекты | Используйте 64-разрядную версию IIS Express

Надеюсь, что это поможет кому-то еще с тем же сценарием и выпуском

Ответ 4

Попробуйте выполнить настройку "Копировать локальную" в проводнике решений для этих сборок и убедитесь, что они удаляются в папку, указанную в журнале привязки.

Кроме того, они, вероятно, были построены с использованием V2 CLR. Если бы это было так, вам нужно включить привязку смешанного режима, добавив это в конфигурацию вашего веб-сайта/приложения

<configuration>
   <startup  useLegacyV2RuntimeActivationPolicy="true">
       <supportedRuntime version="v4.0"/>
  </startup>
</configuration> 

Ответ 5

Я знаю, что это старый вопрос, но все же кажется популярным результатом при поиске решения относительно частичной ошибки привязки в Visual Studio. Я столкнулся с очень похожими проблемами с оригинальным плакатом, но с проектом EntityFramework.dll и Visual studio 2015 (проект ASP.NET Web Forms), однако, найденное мной решение относится к широкой проблеме. Поскольку я не нашел ответов, подобных моему решению, я подумал, что было бы полезно внести то, что я нашел, и надеюсь, что это поможет кому-то.

В моем web.config я выдаю себя за пользователя домена, который является учетной записью службы. У этой учетной записи службы не был доступ к папке временных файлов, поэтому при ее отладке она не могла скопировать DLL файлы и, следовательно, не могла их загрузить.

Что, наконец, привело нас в прошлое и физически выглядело во временной папке, упомянутой в сообщении об ошибке. В исходном вопросе выше вы увидите строки "Попытка загрузки нового файла URL:///C:/Windows/Microsoft.NET/Framework/v4.0.30319/Temporary ASP.NET Files..." Когда я посмотрел в этой папке моих DLL не было.

Решение для меня было следующим: поскольку я использовал 64-битную среду и выдавал себя за учетную запись домена, я добавил пользователя учетной записи службы домена в свой локальный C:/Windows/Microsoft.NET/Framework64/v4.0.30319/Temporary ASP.NET Files с возможностью записи (и изменения - для хорошей оценки).

Нижняя строка - убедитесь, что папка с файлами Temp предоставляет доступ для записи пользователю, на котором работает ваше приложение.

Ответ 6

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

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>

Ответ 7

Я получал ошибку при попытке запустить веб-приложение из Visual Studio, но в моем случае ответ был прост. Когда я внимательно прочитал это исключение, я увидел, что данная сборка больше не используется приложением, но копия все еще находится в папке bin. После того как удаленная сборка была удалена, ошибка исчезла.

Ответ 8

В моем случае я прошел через свой сайт и заменил имя сайта новым именем. Я непреднамеренно заменил "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, как это было до изменения имени (в результате чего запись, совпадающая с именем встроенной сборки), разрешила мне ошибку.

Ответ 9

В моем случае у меня было какое-то дерьмо в моем web.config, в частности, наполовину прокомментировал httpHandler, что, как только я его очистил, моя проблема с привязкой исчезла.