Комментарии 18
Постоянно пользуюсь этим продуктом и есть даже внутренний репозиторий. Для меня есть существенный недостаток, который немного напрягает - это автоматическое инкрементирование версий пакетов в соответствии с версиями сборок. Нет ли информации как можно автоматизировать сборку пакета в соответствии с версией сборки?
пользуюсь этим продуктом
Простите, а этим - это каким? В смысле, как именно собираете пакет? Насколько я понял, версия берётся из .nuspec, а туда при желании можно вписать вообще что угодно.
Играл давеча с созданием нугетов и заливкой в GitHub Packages, вот пример минималистичного воркфлоу, версия подставляется из конфига, при этом там можно написать что угодно:
Simple GitHub action to build NuGet package
или альтернативный вариант, в котором пакет собирается по пушу тега, а версия берётся из названия этого тега (но это оказалось менее удобно)
Речь про nuget, конечно. Я имею в виду возможность задавать версию при локальной сборке по событию после успешного завершения сборки проекта. У меня происходит автоматический инкремент версии сборки в Visual Studio. Хочу видеть автоматический update номера версии в новом пакете nuget. Т.е.:
Изменения в проекте
Запуск сборки с автоматическим изменением версии
Создание локального пакета Nuget с обновлением версии пакета в п.2
Нужен п.3
Добавить в проект кастомный таргет с запуском команды пересборки пакета? В .csproj (в предположении, что версия доступна через пропертю)
...
<Target Name="BuildNugetPackage" AfterTargets="Build">
<Exec Command="nuget pack .\package.nuspec -Version $(PackageVersion)" />
</Target>
...Прям мистика какая-то:
В справке самого пакета nuget нет параметра -Version. Однако он показывает его только если попросить справку по команде "pack":
Вы себе не предствляете, сколько я перечитал в своё время документации по поиску этой информации! И только как я увидел ваш пример, так это и помогло решить мою проблему! Только у меня в проекте на $(PackageVersion) , а@(VersionNumber) и использую я его в Build Events\Post build
Спасибо! Заработало.
Я в итоге для себя решил проблему с версионированием с помощью Conventional Commits спецификации. Сделал пакет, который автоматически присваивает версии, основываясь на feat:/fix:/BREAKING CHANGE префиксах к коммитам и вашей истории в git. Работает в том числе локально.
Вот здесь можно подсмотреть target, который переопределяет версию пакета во время сборки, его можно переписать на ваши условия:
https://github.com/HavenDV/ConventionalCommitsGitInfo/blob/main/src/libs/ConventionalCommitsGitInfo/build/ConventionalCommitsGitInfo.targets
Хотя по сравнению с nodejs и гошниками, ситуация с c# ещё детский лепет. Там вообще оторопь берёт.
Пожалуйста, про гошников поконкретнее.
Не знаю, есть ли аналог такого приложения на C# (чтобы сравнить кол-во), но если пробежаться по зависимостям, то наверно что-то и окажется в стандарном .Net, но скорее всего в разы количество внешних пакетов не сократится.
В Go все пакеты распространяются в виде исходников — нет такой проблемы, что в репозитории один код, а в nuget/npm выложено что-то другое. Это же упрощает навигацию по внешним исходникам, их отладку и модификацию. Можно стандартным тулингом все внешние пакеты завендорить (все внешние исходники будут в папке vendor), провести их полный аудит, а затем при обновлении зависимостей проверять уже только диффы в папке vendor.
Для го это нормально, когда зависимости тянут 5 разных версий одного пакета?
github.com/blevesearch/zapx/v11 v11.3.4 // indirect
github.com/blevesearch/zapx/v12 v12.3.4 // indirect
github.com/blevesearch/zapx/v13 v13.3.4 // indirect
github.com/blevesearch/zapx/v14 v14.3.4 // indirect
github.com/blevesearch/zapx/v15v15.3.4// indirectМоя мечта сделать нечто похожее на nuget, но для исходников
Теоретически в нугеты можно класть что угодно, и сорцы в том числе. Например, https://stackoverflow.com/a/52885223/7468485
при желании не всё, а только нужное
Теоретически в нугет можно положить хитро настроенный .targets с блекджеком пропертями и кондишионами. Вот пример с условием по $(Platform) . Ну или разбить на несколько пакетов и инклюдить каждый по необходимости
Когда то пытался сделать что-то похожее, с указаний версий и зависимостей методов в CDATA. Добавление методов происходило через авто-дополнение с помощью расширения.
https://github.com/HavenDV/OneCode
https://github.com/HavenDV/CSharpUtilities/blob/master/NetStandard20/Utilities/ResourcesUtilities.cs
Но в итоге понял, что это того не стоит. Сейчас многие из этих extensions использую в генераторах, которые добавляют его при необходимости, например: https://github.com/HavenDV/H.Resources.Generator
Если серьезно подходить, то одним пакетным менеджером даже с собственными пакетами ограничиваться недостаточно. Один пакет тащит другой, а тот следующий. По-хорошему надо SBOM генерировать, а на выявленные компоненты анализатор уязвимостей, а потом смотреть, что с тем ужасом, который получится делать.
Вариант с ручным созданием .nuspec файла устарел, сейчас SDK-like проекты генерируют его автоматически на основе MSBuild свойств:
https://docs.microsoft.com/ru-ru/nuget/create-packages/creating-a-package-msbuild
Ответственное управление пакетами в Visual Studio