ых компьютеров через общую папку. В моем случае clean + reabuild не помогло. Пришлось удалить папки bin и объектов из выходного каталога.

когда версия одной из библиотек среды тестирования не соответствует среде разработки.

Очистите и постройте свое решение и перенесите все свои библиотеки DLL в среду, где происходит ошибка, которая должна ее исправить

секцию времени выполнения в web.config, где была запрошенная dll:

  <runtime>
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
      <dependentAssembly>
        <assemblyIdentity name="DotNetOpenAuth.Core" publicKeyToken="2780ccd10d57b246" />
        <bindingRedirect oldVersion="0.0.0.0-4.1.0.0" newVersion="4.1.0.0" />
      </dependentAssembly>
.
.
.
  <runtime>

и я запустил «зависящий от файла» на dll, о котором идет речь. Это показало мне, что dll была скомпилирована в x86, а некоторые зависимости были скомпилированы в x64.

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

Мои проблемы решены путем удаления всей части времени выполнения

<runtime>
        <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
            <dependentAssembly>
                <assemblyIdentity name="System.Web.Helpers" publicKeyToken="31bf3856ad364e35"/>
                <bindingRedirect oldVersion="1.0.0.0-3.0.0.0" newVersion="3.0.0.0"/>
            </dependentAssembly>
            <dependentAssembly>
                <assemblyIdentity name="System.Web.WebPages" publicKeyToken="31bf3856ad364e35"/>
                <bindingRedirect oldVersion="1.0.0.0-3.0.0.0" newVersion="3.0.0.0"/>
            </dependentAssembly>
        </assemblyBinding>
    </runtime>

ней версии (используя NuGet), но это противоречило зависимостям. Я вручную добавил приведенный ниже код в web.config, и это сработало.

<dependentAssembly>
    <assemblyIdentity name="WebGrease" culture="neutral" publicKeyToken="31bf3856ad364e35" />
    <bindingRedirect oldVersion="0.0.0.0-1.6.5135.21930" newVersion="1.6.5135.21930" />
</dependentAssembly>

Обратите внимание, что мое решение будет работать только тогда, когда ошибка связана с WebGrease. Код ошибки останется прежним. Также вам необходимо изменить версию в oldVersion и newVersion соответственно.

udio, -Microsoft.VisualStudio.TemplateWizardInterface - (после попытки установить странные инструменты разработки)

рассмотреть это решение (любезно предоставлено larocha (спасибо, кто бы вы ни были)):

<dependentAssembly><br><!-- assemblyIdentity name="Microsoft.VisualStudio.TemplateWizardInterface" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" / --><br><bindingRedirect oldVersion="0.0.0.0-8.9.9.9" newVersion="9.0.0.0" /><br></dependentAssembly>

источник:http://webclientguidance.codeplex.com/workitem/15444

g Assistant при первой десериализации XML-файла в объекты в VS2010 / .NET 4. DLL-библиотека, содержащая классы для объектов, генерируется в событии после сборки (обычные вещи в стиле Microsoft). Очень хорошо сработало несколько проектов в одном решении, проблема возникла при выполнении этого в еще одном проекте. Текст ошибки:

Обнаружена ошибка привязки. Сообщение: не удалось загрузить сборку с отображаемым именем MyProjectName.XmlSerializers в контексте привязки «LoadFrom» для AppDomain с идентификатором 1. Причина ошибки: System.IO.FileLoadException: Не удалось загрузить файл или сборку. MyProjectName.XmlSerializers, версия = 1.0.0.0, культура = нейтральная, PublicKeyToken = null 'или одна из ее зависимостей. Определение манифеста обнаруженной сборки не соответствует ссылке на сборку. (Исключение из HRESULT: 0x80131040)

Поскольку некоторые ответы здесь предполагали несоответствие платформы, я заметил, что для 3 проектов и решения выбрана конфигурация «смешанных платформ», и 3 проекта были скомпилированы для x86 вместо AnyCPU. У меня нет специфичного для платформы кода (хотя некоторые предоставляемые вендором библиотеки DLL используют несколько библиотек x86). Я заменил все вхождения x86 в AnyCPU следующим образом:

for a in $( egrep '(x86|AnyCPU)' */*.csproj *.sln -l  ) ; do echo $a ; sed -i 's/x86/AnyCPU/' $a ; done

Затем проект будет построен, но все параметры для запуска или отладки кода будут недоступны. Перезапуск VS не помог бы.

Я вернул git ссылки на библиотеку x86, на всякий случай, но сохранил AnyCPU для всего кода, который я компилирую.

СледующийF5 или кнопка «Начать отладку» неактивна для приложения Winform? Я выгрузил и перезагрузил стартовый проект (это был тот, где изначально возникла первоначальная проблема).

После этого все стало на свои места: программа работает без первоначальной ошибки.

Видетьhttp://www.catb.org/jargon/html/R/rain-dance.html , http://www.catb.org/jargon/html/V/voodoo-programming.html или жеhttp://www.catb.org/jargon/html/I/incantation.html и ссылки там.

Проект Api использовал пакет nuget библиотеки с версией 3. И одна из упомянутых сборок говорит, что X использовал более старую версию того же пакета nuget с версией 2.

При сборке ссылочной сборки или перестройке любого другого проекта, ссылающегося на X, сборки api-проекта обновляются до более низкой версии. И получил эту ошибку ссылки сборки.

Восстановление работает, но в моем случае я хотел долгосрочного решения.

Я сделал сборку, ссылающуюся на ту же версию пакета nuget.

когда он не мог найти сборку PayPal, и это было потому, что я назвал свое решение PayPal. Я уверен, что это не будет ответом ни для кого, но думал, что я поделюсь этим в любом случае:C # ASP.NET MVC PayPal не находит сборки

когда я обновил web.config, не обновляя все упомянутые dll.

Используя правильный diff-фильтр (остерегайтесь фильтра сравнения по умолчанию каталога Meld, игнорируя двоичные файлы), была обнаружена разница, файлы были скопированы, и все работало нормально.

CreateObject сделано в VBScript. Причиной в моем случае была версия сборки, которая находилась в GAC, которая была старше той, которую я скомпилировал. (пытаясь решить более раннюю проблему, я установил сборку в GAC).

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

DLL, на которую ссылается сборка, не имеет ожидаемой сигнатуры метода.

Очистите решение, восстановите все и попробуйте снова.

Кроме того, будьте осторожны, если это ссылка на что-то, что находится в GAC; Возможно, что-то указывает на неверную версию. Убедитесь (через Свойства каждой ссылки), что выбрана правильная версия или что для Конкретной версии установлено значение false.

Просто проверьте ваш файл webconfig и удалите этот код: -

<dependentAssembly>
    <assemblyIdentity name="itextsharp" publicKeyToken="8354ae6d2174ddca" culture="neutral" />
    <bindingRedirect oldVersion="0.0.0.0-5.5.13.0" newVersion="5.5.13.0" />
  </dependentAssembly>

но за последние пару дней «обновился» до 2017 года. Решение было закрыть и снова открыть VS.

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

Msgstr "Ошибка HRESULT E_FAIL возвращена при вызове COM-компонента."

Мой обходной путь - закрыть решение, снова открыть в VS2012, добавить ссылку, закрыть 2012 и открыть 2017. Смешно, что 2017-й должен был быть выпущен с такой очевидной ошибкой.

В моем случае я получил это сообщение во время отладки:

"Error while calling service <ServiceName> Could not load file or assembly 'RestSharp, 
Version=105.2.3.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. 
The located assembly's manifest definition does not match the assembly reference.
(Exception from HRESULT: 0x80131040)"

причина

В моем проекте было 2 внутренних компонента, использующих RestSharp, но оба компонента имеют разные версии RestSharp (один с версией105.2.3.0 а другой с версией106.2.1.0).

Решение

Либо обновите один из компонентов до более нового, либо понизьте рейтинг другого. В моем случае мне было безопаснее понизить рейтинг106.2.1.0 в105.2.3.0 и чем обновить компонент в диспетчере пакетов NuGet. Таким образом, оба компонента имеют одинаковую версию.

Восстановите, и это работало без проблем.