Переадресация привязок добавляется в каждый файл app.config

Question

У меня есть 20 проектов в файле решения. Один из проектов - это стандартный библиотечный проект, на который ссылаются все проекты.

Около года назад мы добавили новый пакет Nuget, назовем его Package A Версия 5.0.0.0. Он имел кучу файлов, которые он передавал во время компиляции, но мы в конце концов справились с этим. Мы добавили пакет в наш стандартный библиотечный проект (один из которых 19).

Я новичок в Nuget (так что, возможно, я сделал что-то не так), поэтому я сделал новый пакет, чтобы служить помощником для Package A, Я все настроил так, чтобы у помощника была зависимость от Package A версии 3.0.0.0 до 5.0.0.0 (так что это работает для тех, у кого более низкая версия, чем у нас). Давайте назовем этот новый пакет Package A helper

Я устанавливаю Package A helper и все работает как надо. Я иду, чтобы сделать запрос извлечения, и каждый app.config в нашем решении теперь имеет

<runtime>
      <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
              <dependentAssembly>
                      <assemblyIdentity name="Package.A" publicKeyToken="8FC3CCAD86" culture="neutral"/>
                      <bindingRedirect oldVersion="0.0.0.0-5.0.0.0" newVersion="5.0.0.0"/>
              </dependentAssembly>
      </assemblyBinding>
</runtime>

Без компиляции будет нормально, но visual studio жалуется и выдает предупреждение. Что дает? Мой менеджер не позволит мне объединить мой код сейчас, потому что он добавляет слишком много шума в app.config и слишком сильно зависит от пакета A.

почему добавили пакет nuget, который зависел от Package A затем должен иметь этот новый bindingRedirect, когда основная зависимость уже была достигнута, прежде чем мы установили Package A Helper?

И почему он говорит 0.0.0.0-5.0.0.0, когда я указал 3.0.0.0-5.0.0.0 в пакете nuget и package.config

Обновить:

Когда я строю Package A helper со ссылками на Package A версии 5.0.0.0, тогда все bindingRedirects не заполняются автоматически в каждом app.config, а вместо этого генерируются предупреждения. Первоначально я построил его с 3.0.0.0, потому что решил, что лучше всего построить его с самой низкой зависимостью. Проблема все еще существует, потому что Visual Studio все еще предупреждает и предлагает создание bindingRedirects.

No way to resolve conflict between "Package A, Version=5.0.0.0, Culture=neutral, PublicKeyToken=83hfhsd33" and "Package A, Version=3.0.0.0, Culture=neutral, PublicKeyToken=83hfhsd33". Choosing "Package A, Version=5.0.0.0, Culture=neutral, PublicKeyToken=83hfhsd33" arbitrarily.
Consider app.config remapping of assembly "Package A, Culture=neutral, PublicKeyToken=83hfhsd33" from Version "3.0.0.0" [] to Version "5.0.0.0" [path to Package A dll] to solve conflict and get rid of warning.

Является ли решение просто изменить мою зависимость пакета nuget с 3.0.0.0 на 5.0.0.0 и просто разрешить 5.0.0.0 и избавиться от моего allowedVersions="[3,6)" во мне packages.config? Я не хочу уменьшать полезность и обратную совместимость моего пакета nuget, но в то же время я не хочу предупреждений или bindingRedirects, необходимых для моего основного решения.

Обновление 2: настройка Copy Local в ссылочных свойствах False на самом деле решил мои проблемы, но я не понимаю, почему.

Answer 1

Первоначально я построил его с 3.0.0.0, потому что я подумал, что это было лучше...

Вот где проблема началась. Ваше решение теперь зависит от двух разных версий A.dll, одна из которых перезапишет другую. Какая версия A.dll заканчивается копированием в bin\Debug - это случайно. Какой бы проект ни был построен последним.

Это не может прийти к хорошему концу, решение обречено на неудачу для выполнения. Если в коде A-helper.dll будет указан какой-либо код, произойдет сбой, когда будет завершено копирование версии 5.0.0.0. Или это будет код в любом другом проекте, использующем A.dll, он потерпит неудачу, когда будет скопирована версия 3.0.0.0. Конечным результатом является то, что решение всегда будет неудачным.

Итак, вы видите, что система сборки что-то делает с этим. Он замечает несоответствие и выбирает одну из версий для победы. Он выбирает 5.0.0.0, это был правильный выбор. Он также изменяет app.config, добавляя bindingRedirect, чтобы код, запрашивающий загрузку версии 3.0.0.0, фактически получал 5.0.0.0. Это может сработать, если вы сделаете версию 5 достаточно совместимой с версией 3. Или нет, два увеличения основного номера версии обычно приводят к проблемам. Вы узнаете, когда будете тестировать.

Так что установка "Копировать локально" в свойствах ссылки на "Ложь" фактически решила мои проблемы

Это не решило проблему, вы просто помешали системе сборки предположить, что она решит эту проблему для вас. Поскольку ему больше не нужно было копировать DLL, он предполагает, что вы будете устанавливать сборки в GAC, чтобы обе версии могли сосуществовать. Может быть, вы сделали, это не распространено и вообще очень неразумно делать это на компьютере разработчика. Очень маловероятно, что вашему боссу и членам команды это решение понравится с учетом дополнительного шага установки.

---

Итак, есть две основные вещи, которые вы можете сделать:

• Позвольте системе сборки разобраться с этим. После этого проблема была решена правильно, и ваше решение будет работать. Если версия 5 достаточно совместима с версией 3, тогда код в A-helper.dll будет даже работать правильно. Если боссу это не понравится, вам, конечно, придется поцарапать это и сделать:

• Измените ссылку в проекте A-helper на версию 5.0.0.0. Теперь больше нет никакой несовместимости, один-единственный A.dll хорош для всего кода. Учитывая ваше требование, это единственное решение, которое понравится вашему боссу.