Печально известная ошибка привязки сборки
Мне действительно нужна помощь в этом, потому что я потерял надежду исправить проблему.
Я использую 64-битные библиотеки Office Communications Server. Есть 3 DLL, которые я использую в проекте, Microsoft.РЦТ.Сотрудничество.dll, Microsoft.РЦТ.Внутренний.Сми.dll и SIPEPS.файл DLL. Я не уверен насчет Microsoft.РЦТ.Сотрудничество, но внутреннее.Media и SIPEPS - это x64. В списке сборок GAC Rtc.Совместная работа показывает MSIL под процессорной архитектурой, а другие показывают Для amd64.
мой проект компилируется без ошибок с этими ссылками, но во время выполнения я получаю сообщение об ошибке:
не удалось загрузить файл или сборку 'Microsoft.РЦТ.Внутренний.Media ' или одна из его зависимостей. Была сделана попытка загрузить программу, имеющую неверный формат.
Я попытался скомпилировать проект с процессором, установленным на любой процессор, но ничего не изменилось. С обоих под x64 и x86 настройки я получаю эту ошибку.
любая помощь оцененный.
обновление: Ниже приведен журнал привязки сборки.
=== Pre-bind state information ===
LOG: User = CONTOSOelodie
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:UserselodieDocumentsVisual Studio 2010ProjectsTFSprotoMainSourceWebBot.Webbin
Calling assembly : (Unknown).
===
LOG: This bind starts in default load context.
LOG: Using application configuration file: C:UserselodieDocumentsVisual Studio 2010ProjectsTFSprotoMainSourceWebBot.Webweb.config
LOG: Using host configuration file:
LOG: Using machine configuration file from C:WindowsMicrosoft.NETFrameworkv4.0.30319configmachine.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.
10 ответов:
У меня была эта проблема с ASP.NET IIS и после того, как я попробовал все, я включил 32-бит для своего пула приложений и перезапустил пулы приложений. Потом это сработало.
в Диспетчере служб IIS 7: Пулы приложений - > DefaultAppPool - > Дополнительные параметры- > установите "включить 32-разрядные приложения" в true.
также убедитесь, что выбрана правильная версия .Net.
Я также установил ISAPI 64bit разрешенным в разделе "Ограничения ISAPI и CGI", но я не уверен, что это помог.
в моем случае я получил эту проблему, потому что я запускал веб-проект, скомпилированный для x64 с помощью IISExpress. Я исправил эту проблему, проверив следующий параметр в Visual Studio:
Инструменты / Параметры / проекты и решения / веб-проекты / используйте 64-разрядную версию IIS Express
надеюсь, что это поможет кому-либо еще с этим же сценарием и проблемой
заменены 64-битные версии всех трех DLL с их 32-битными версиями, очищены временные ASP.NET файлы папки и снова скомпилированы. Теперь работает без проблем. Спасибо за помощь.
попробуйте установить параметр копировать локально в обозревателе решений для этих сборок и убедитесь, что они удаляются в папку, указанную в журнале привязки.
кроме того, они, вероятно, были построены с использованием среды CLR V2. Если они были, вам нужно будет включить привязку смешанного режима, добавив это в свою конфигурацию web/app
<configuration> <startup useLegacyV2RuntimeActivationPolicy="true"> <supportedRuntime version="v4.0"/> </startup> </configuration>
чтобы решить эту проблему, я обеспечил, чтобы все мои проекты использовали одну и ту же версию, выполнив следующую команду и проверив результаты:
update-package Newtonsoft.Json -reinstallи, наконец, я удалил следующее из моей сети.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 project), однако решение, которое я нашел, относится к широкой проблеме. Поскольку я не нашел ответов, подобных моему решению, я подумал, что было бы полезно внести свой вклад в то, что я нашел, и я надеюсь, что это действительно помогает кому-то.
в моем web.конфигурация я олицетворяю пользователя домена, который является учетной записью службы. Эта учетная запись службы не имела доступа к папке "Мои временные файлы", поэтому при отладке она не могла скопировать библиотеки DLL и, следовательно, не могла их загрузить.
что, наконец, опрокинуло нас, шло и физически искало во временной папке, упомянутой в сообщении об ошибке. В исходном вопросе выше вы заметите строки " попытка загрузки новых URL типа File:///с:/Windows и Microsoft.Объем/рамках/В4.0.30319/временные файлы ASP.NET ..."Когда я заглянул в эту папку, моих DLL там не было.
решение для меня было следующим: поскольку я использовал 64-битную среду и олицетворял учетную запись домена, я добавил пользователя учетной записи службы домена в свой локальный C:/Windows/Microsoft.NET/Framework64/v4.0.30319/Temporary ASP.NET папка файлов с доступом для записи (и изменения - для хорошей меры).
итог - убедитесь, что ваш Папка Temp files предоставляет доступ на запись пользователю, от имени которого выполняется приложение.
Я получал ошибку при попытке запустить веб-приложение из Visual Studio, но в моем случае ответ был прост. Когда я внимательно прочитал исключение, я увидел, что рассматриваемая сборка больше не используется приложением, но копия все еще находится в папке bin. После того, как нарушителя сборки был удален, ошибка исчезла.
Это старый вопрос, но все еще был верхний результат, когда у меня была эта же проблема сегодня. Я переключил свою компиляцию проекта в Visual Studio на целевой x64 вместо "все процессоры" (это на 64-разрядной машине). Согласно другим ответам, было бы два способа исправить это - либо изменить все на 32-бит, либо все на 64-бит. В этом случае мне нужен 64-битный.
KabanaSoft это прекрасно работал для меня. По-прежнему правильно с Visual Studio 15.6.6.
в моем случае я прошел через мой сайт и заменил имя сайта с новым именем. Я случайно заменил "PreviousWebSiteName" на "NewWebSiteName" в Интернете.конфигурация, в которой указывается имя сборки.
<pages enableSessionState="false" enableViewStateMac="true" enableEventValidation="true" controlRenderingCompatibilityVersion="4.0" clientIDMode="AutoID"> <controls> <add assembly="NewWebSiteName" namespace="App_Code.Controls" tagPrefix="blog" /> </controls> </pages>сайт все еще строил сборку со старым именем - я только намеревался изменить имя сайта, где оно появлялось на страницах сайта; мне не нужно было ничего менять внутри. Восстановление сети.запись конфигурации как она было до того, как мое изменение именования (в результате чего запись, которая соответствует имени встроенной сборки) разрешила ошибку для меня.