Можно ли разрабатывать, используя локальные проекты, вместо того, чтобы публиковать каждое изменение в nuget?

Question

Я пишу код для проекта, в котором есть несколько приложений на основе Azure, а также несколько служб Windows и т. Д. Излишне говорить, что это просто набор отдельных приложений, которые развернуты в Azure или в другом месте и ожидаются все должны работать вместе.

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

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

До использования Nuget мы, возможно, только что добавили все эти проекты в качестве прямых зависимостей на диске, что удаляет управление версиями, но сразу позволяет мне развиваться против моих локальных изменений.

Теперь с Nuget я не могу развиваться против локальных изменений, не выдвинув новый пакет.

Есть ли какой-то рабочий процесс, который мне не хватает, который позволил бы мне по-прежнему использовать Nuget, но также иметь возможность вносить изменения и работать локально, без необходимости постоянно загружать и извлекать пакеты Nuget?

Могу ли я как-то развиваться против локальных проектов, но также как-то знать зависимости проекта для использования пакетов Nuget?

Answer 1

Я столкнулся с этой проблемой при настройке общего репозитория NuGet для моей компании. Вы можете настроить локальный канал NuGet и «публиковать», просто перетаскивая файлы в папку. Это очень полезно для локального тестирования, прежде чем вы будете готовы к публикации в общем репо.

Кроме того, NuGet использует семантическое управление версиями . Я считаю полезным иметь предварительные версии с использованием тега, подобного MyLibrary.1.0.0-prerelease-12345, чтобы у вас все еще могли быть инкрементные сборки, но большинство других приложений не будут уведомлены об изменениях, пока вы не создадите основной выпуск, такой как MyLibrary.1.0.1. Для этого может потребоваться внести некоторые изменения в процесс DevOps, но это позволит нескольким разработчикам протестировать ваш пакет перед его «официальным» выпуском.

Если ваша проблема в том, что вы хотите иметь возможность легко обновлять несколько приложений локально и тестировать эти изменения. Я иногда находил полезным создание единого файла решения, охватывающего все мои проекты, чтобы я мог быстро открывать, обновлять и создавать все в одном экземпляре Visual Studio. Однако это решение не особенно масштабируемо, поэтому вам может быть лучше написать сценарии PowerShell для автоматизации.

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

Answer 2

Учитывая, что все проекты находятся в одном репо, просто используйте ссылки на проекты вместо ссылок на пакеты.

Когда вы упаковываете проект, NuGet преобразует ссылки на проекты в зависимости NuGet, и версия зависимости будет такой же, как и у другого проекта, если / когда он упакован.