Visual Studio продолжает перезаписывать NewtonSoft.Json.DLL со старой версией

Visual Studio перезаписывает правильную версию NewtonSoft.Json.DLL, которую я сконфигурировал как в моих проектных ссылках, так и в файле пакета NuGet со старой версией, когда я создаю любой другой проект, кроме веб-сайта, содержащего ссылку.

OK. Вот сценарий:

У меня есть решение с бэкэнд-сервисом и веб-сайтом. Веб-сайт работает на .NET 4.5 и настроен с помощью NuGet, чтобы вытащить версию 6.0.1 Newtonsoft.Json.DLL.

<package id="Newtonsoft.Json" version="6.0.1" targetFramework="net45" />

Что добавляет привязку dependenAssembly к файлу 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>

Я могу создавать и запускать этот сайт без каких-либо проблем.

Недавно я обновил все библиотеки классов и вспомогательные службы с .NET 4.0 до .NET 4.5. После обновления всякий раз, когда я создаю одну из библиотек классов или запускаю/отлаживаю серверную службу, веб-сайт становится неработоспособным.

Could not load file or assembly 'Newtonsoft.Json' or one of its dependencies. The located assembly manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)

Я проследил это за тем, что при перестройке одной из библиотек классов или запуске/отладке бэкэнд-сервиса из Visual Studio, Newtonsoft.Json.DLL перезаписывается более старой версией файла - версия 4.5.11. Из-за явной привязки dependAssembly, когда я получаю доступ к веб-сайту после этого, я получаю ошибку "Не могу загрузить...", упомянутую выше.

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

Как я могу запретить Visual Studio переписывать DLL?

Обратите внимание, что у меня есть набор ссылок только для 6.0.1 для всего решения (т.е. нет ссылки нигде на 4.5.11). И на веб-сайте у меня есть "Скопировать локальный", установленный в true, и "Специфическая версия" также установлена ​​в значение true для Newtonsoft.Json.DLL.

Ответы

Ответ 1

Это известная ошибка в Windows Azure VS Tools

Обходные пути:

  • Удалите файл Newtonsoft.Json.dll из Program Files\Microsoft SDK\Windows Azure.NET SDK\v2.3\ref\папка.

  • Удаление Windows Azure VS Tools v 2.3

Ответ 2

Вот такая ситуация.
3 проекта в решении. Проекты A и B ссылаются на Newtonsoft.Json.DLL 6.0.3 и ссылку на решение для проекта C. Проект C не имеет никакой явной ссылки на Newtonsoft.Json.DLL.
При построении решения он строит C, затем A и B - отбрасывает правильную dll в bin. Но когда я строю только C VS, катит более старую версию dll к A и B. Поскольку явная ссылка или привязка Redirect не существует, она берет ее из GAC. Также Building только A катит более старую dll в B, потому что он строит C сначала сбрасывает неправильную версию в и B, а затем строит A, помещая правильную версию.

Вот решение - явно добавьте Newtonsoft.Json.DLL 6.0.3 в проект C

Ответ 3

Мой сценарий был почти таким же, за исключением того, что моя Newtonsoft.JSON DLL была скопирована из другого места. Я подтвердил, что мое решение ссылалось на правильный файл и версию, но на RUN VS скопировал его из другого места (сначала проверьте это, перетащив BIN DLL в VS или свойства.

В конце после попытки их по одному с помощью Журналы Fusion Я пошатнулся, заменив все ссылки Newtonsoft.JSON.dll, который имеет такая же неправильная версия из файлов программы:

  • 'C:\Program Files (x86)\Microsoft SDK\Microsoft Azure\Mobile Услуги \1,0'
  • 'C:\Program Files\Common Files\Microsoft Shared\Visual Студия \12,0'
  • 'C:\Program Files (x86)\Microsoft Visual Studio 12,0\смесь
  • и др.

Краткая подсказка: в раскрывающемся списке explorer добавьте "Версия продукта" в качестве столбца и выполните его сортировку: введите описание изображения здесь

По-прежнему кажется, что это дерьмовое поведение IDE, если я установил Конкретную версию для этой сборки, а путь к файлу - в правильную DLL (установленную NuGet), она не должна действительно переходить и переопределять ее с помощью одного из другого общего глобального местоположения. Любые комментарии для изменения поведения сборки Visual Studio здесь будут оценены, поскольку я действительно не хочу делать этот тип ручных хаков на каждой машине разработчиков.

введите описание изображения здесь

Ответ 4

Сегодня я столкнулся с такой же проблемой. Я обнаружил, что после сборки библиотеки классов все файлы *.dll в каталоге вывода библиотеки классов копируются в папку bin любого веб-проекта, который имеет ссылку на проект для этой библиотеки классов. Это может привести к замене совместимых сборок на несовместимые сборки. Однако эта dll xcopy не будет выполняться, когда веб-проект будет выгружен (щелкните правой кнопкой мыши проект и выберите "Unload Project" ).

Ответ 5

Недавно мы столкнулись с той же проблемой. Наше решение будет компилировать и иметь правильные DLL на наших машинах разработки, но в нашем агенте сборки неправильная версия Newtonsoft.Json будет удалена в выходных папках.

После долгого времени мы обнаружили, что это было вызвано тем, кто установил более новую версию Azure SDK в нашем агенте сборки, чем у нас был локально: 2.9 вместо 2.5.1.

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

Ответ 6

У меня точно такая же проблема, и выяснилось, что в C:\Program Files\Microsoft SDKs\Windows Azure.NET SDK\v2.3\ref У меня есть Newtonsoft.Json.dll с теми же датами и датами, что и тот, который скопировал в папку моего веб-сайта.

После переименования/удаления Newtonsoft.Json.dll в C:\Program Files\Microsoft SDKs\Windows Azure.NET SDK\v2.3\ref Visual Studio перестала заменять мою ссылочную версию, и веб-сайт снова начал работать.

Ответ 7

Проблема

Ваш csproj содержит ссылку с недопустимым путем к DLL Newtonsoft.Json. В моем случае это было

<HintPath>..\..\packages\Newtonsoft.Json\lib\net45\Newtonsoft.Json.dll</HintPath>

вместо того, чтобы NuGet должен был установить packages\Newtonsoft.Json.8.0.3\... (включая номер версии).

Так как VS не может найти dll, он будет просто искать в вашей системе и использовать первый найденный. В моей системе это Azure SDK 2.9, затем Azure SDK 2.8, затем VS12/Blend/....

Решение

Некоторые из вышеперечисленных решений (удаление всех найденных в вашей системе файлов Newtonsoft.Json.dll) могут скрыть проблему в краткосрочной перспективе, , но только исправление csproj, указывающее на правильный путь, поставляемый NuGet, будет действительно решить проблему.

То есть убедитесь, что HintPath в вашем csproj соответствует пути пакета, где установлен пакет NuGet.

Если у вас есть bash, вы можете использовать

$ grep -r HintPath * | grep Newtonsoft

в корневом каталоге вашего решения, чтобы найти оскорбительный csproj.

Связанные ошибки

Если у вас возникла эта проблема, запуск вашего сайта Asp.Net с явным перенаправлением в файле web.config может завершиться неудачей на странице исключения со следующим текстом в сообщении об ошибке:

LOG: попытка загрузки нового URL-адреса newtonsoft json

WRN: сравнение имени сборки привело к несоответствию: основная версия

Даже если некоторые проекты имеют ссылку на NuGet из Newtonsoft.Json 8.x, VS будет с удовольствием компилироваться, а затем перезаписать эту DLL с древней, найденной в системе, и выйти из строя во время выполнения.

Ответ 8

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

В моем случае я использую VS 2015, проблема была неиспользуемой ссылкой на другой проект в моем приложении, который использует более старую версию newtonSoft. Я устраняю ссылку, и dll больше не изменялась.