Безболезненная локальная разработка, а также ссылка на пакеты NuGet

Я пытаюсь опубликовать и уничтожить версии NuGet пакетов библиотек классов, избегая головных болей для локальной разработки. Вот образец макета решения Visual Studio:

| Libraries
  | LibraryA
  | LibraryB
  | LibraryC
| Applications
  | ApplicationD
  | ApplicationE

Это единственное решение, содержащее как библиотеки разделенных классов, так и несколько приложений. В настоящее время ссылки на библиотеки классов приложениями являются локальными ссылками в решении.

Мне хотелось бы опубликовать библиотеки (A, B, C) в виде пакетов NuGet с версией, которые затем используются приложениями (D, E). Это позволяет изменять независимую библиотеку от обновления до приложения, которое развертывается. Без этого изменение одной библиотеки может привести к изменению двоичных файлов в десятках или более приложений, все из которых будут технически нуждаться в проверке. Это нежелательно, и управление версиями с помощью NuGet исправляет это.

Однако скажем, что я хочу одновременно обновлять содержимое LibraryA и ApplicationD. Чтобы сделать это после того, как мы перешли на NuGet, мне придется внести изменения в LibraryA, зафиксировать их, дождаться создания пакета, сообщить ApplicationD обновить его ссылку на LibraryA, а затем протестировать или разработать в ApplicationD. Это намного сложнее, чем просто работать с обоими одновременно, используя локальные ссылки в решении.

Каков лучший способ повысить надежность версий пакетов NuGet для моих общих библиотек классов, а также упростить разработку, даже если она охватывает несколько проектов и приложений? Единственные другие решения, которые я нашел, включают слишком много накладных расходов или головную боль, например, необходимость постоянно менять ссылки на ApplicationD между пакетом NuGet и локальным проектом.

РЕДАКТИРОВАТЬ: Чтобы уточнить предпосылку, этот вопрос предполагает следующее:

Архитектура (решение и организация проекта) не может быть значительно реорганизована.
Общие библиотеки будут меняться с нетривиальной частотой
Изменение общей библиотеки не может заставить приложение обновляться
Приложения могут ссылаться на разные версии разделяемых библиотек

Ответ 1

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

Внести изменения в библиотеку
Автоматическая сборка и развертывание версии библиотеки, увеличенной на 1 до внутреннего фида NuGet.
Обновить пакет NuGet в потребительском приложении

Весь процесс от регистрации до обновления потребляющего проекта занимает около 3 минут. Репозиторий NuGet также имеет сервер с символами/источниками, который чрезвычайно помогает при отладке.

Ответ 2

Хотя это требует некоторой работы, можно вручную редактировать файлы .csproj, чтобы установить условные ссылки, добавив атрибут Condition к соответствующим ссылкам.

РЕДАКТИРОВАТЬ Я перенес эти условия в ItemGroups, так как, похоже, так работает мой упомянутый производственный код, и было упомянуто о возможной проблеме в VS 2013.

<ItemGroup Condition="'$(Configuration)' == 'Debug Local'">
    <!-- Library A reference as generated by VS for an in-solution reference, children unmodified -->
    <ProjectReference>...
</ItemGroup>

<ItemGroup Condition="'$(Configuration)' == 'Debug NuGet'">
    <!-- Library A reference as generated by NuGet, child nodes unmodified --> 
    <Reference Include="LibraryA">...
</ItemGroup>

Это позволило бы вам иметь в проектах D & E конфигурации "Debug NuGet" и "Debug Local", которые по-разному ссылаются на библиотеки. Если затем у вас есть несколько файлов решений, сопоставление их конфигураций с соответствующими конфигурациями в проектах, конечный пользователь никогда не увидит больше, чем "Отладка" и "Выпуск" для большинства операций, так как это конфигурации конфигурации, и он будет только необходимо открыть полное решение для редактирования проектов A, B и C.

Теперь, что касается извлечения проектов A, B и C, вы можете настроить их в папке, помеченной как подрепортаж (при условии, что вы используете SCM, который поддерживает это, например, Git). Большинству пользователей никогда не потребуется извлекать подпункты, так как они не имеют доступа к проектам ABC, а вместо этого получают данные из NuGet.

В плане обслуживания я могу гарантировать, что VS не будет редактировать условные ссылки и будет уважать их во время компиляции -I как в VS 2010, так и в 2013 году (РЕДАКТИРОВАТЬ: Профессиональная версия, хотя я и проделал то же самое с Express) с такие же условные эталонные проекты на работе. Имейте в виду, что в VS ссылки могут быть независимыми от версии, что делает NuGet единственным местом, где нужно поддерживать версию, и это можно сделать, как и любой другой пакет NuGet. Хотя я надеюсь, я НЕ проверял, будет ли NuGet бороться с условными ссылками.

РЕДАКТИРОВАТЬ Также может быть целесообразным отметить, что условные ссылки могут вызывать предупреждения об отсутствующих DLL, но на самом деле не мешают компиляции или запуску.

РЕДАКТИРОВАТЬ Для тех, кто все еще читает это, я теперь (7/2019) слышу, что среда IDE не так дружелюбна к этим изменениям, и либо она, либо менеджер пакетов могут их переопределить. Действуйте с осторожностью и всегда читайте ваши коммиты!

Ответ 3

Я знаю, что это 2-летний пост, но только что нашел его, столкнувшись с той же ситуацией. Также нашел это для VS2015, я в процессе тестирования. Я вернусь и исправлю свой ответ соответственно.

https://marketplace.visualstudio.com/items?itemName=RicoSuter.NuGetReferenceSwitcherforVisualStudio2015

Ответ 4

Обновление для .NET Core (2.x ++)

.NET Core 2.x на самом деле имеет эту встроенную функциональность!

Если у вас есть ссылка проекта на проект A в проекте B, и проект A является проектом .NET Standard или Core с правильной информацией о пакете (Properties → Package с Package id установлен Package id пакета NuGet), то вы можете иметь обычный ссылка на проект в файле проекта .csproj:

<ItemGroup>
  <ProjectReference Include="..\..\A\ProjectA.csproj" />
</ItemGroup>

Когда вы упаковываете (пакет dotnet pack) проект B из-за Package id в проекте A, сгенерированный файл .nuspec будет настроен с зависимостью NuGet от этого идентификатора пакета вместе с другими ссылками на NuGet, которые у вас могут быть, вместо простого включения встроенный файл DLL.

<dependencies>
  <group targetFramework=".NETStandard2.0">
    <dependency id="Project.A" version="1.2.3" exclude="Build,Analyzers" />
    <dependency id="Newtonsoft.Json" version="12.0.2" exclude="Build,Analyzers" />
  </group>
</dependencies>

Ответ 5

В свойствах ApplicationD перейдите на вкладку " Ссылочные пути " и добавьте путь к выходной папке LibraryA. Затем, если вы измените и соберете LibraryA, следующая сборка ApplicationD будет использовать измененную LibraryA.

Когда вы закончите, не забудьте удалить "Ссылочные пути" и обновить версию пакета NuGet, на которую ссылаются.