Блог

Каково ожидаемое поведение при создании/публикации разных независимых проектов .csproj в одной папке с использованием dotnet publish ?

Представьте, что для этого Alpha.csproj может потребоваться пакет NuGet foo версии 1.0.0, и для этого проекта Bravo.csproj может потребоваться версия 2.0.0 той же зависимости NuGet. Меня беспокоит то, что два отдельных dotnet publish вызова в этих разных проектах, направленных в одну и ту же целевую папку, приведут к foo перезаписи зависимости…таким образом, нарушается развертывание.

Я знаю, что NuGet часто хранит свои двоичные файлы во вложенных папках, часто отличающихся номерами версий, но также часто он помещает зависимости непосредственно в основную папку публикации. Таким образом, по номинальной стоимости есть место для неожиданных конфликтов.

До сих пор я решал эту ожидаемую проблему таким образом, чтобы поместить оба проекта в одно и то же решение, а затем опубликовать решение. Я полагаю, что одна команда публикации достаточно умна, чтобы устранить различия (хранить разные версии зависимостей foo в разных подпапках). Однако, что, если эти проекты находятся в разных решениях?

Я говорю «ожидаемая» проблема, потому что на самом деле я не тратил время на ее решение. У меня сжатые сроки, и я не могу позволить себе иметь дело с потенциально неясными ошибками, возникающими во время выполнения; Я не хочу находить ответ на свой вопрос «трудным путем».

Понимание этой динамики особенно важно для меня, потому что я создаю плагины .Net Core 3.1, которые я хотел бы опубликовать/развернуть в существующей папке платформы. Приложение предназначено для поиска новых плагинов и их загрузки.

Ожидаемое поведение заключается в том, что последний опубликованный проект перезапишет существующие файлы в каталоге публикации и, таким образом, может привести к конфликтам версий зависимостей.

У однофайловых развертываний больше шансов избежать конфликта при публикации в одном каталоге за счет большего общего размера развертывания.