Комментарии 18
Как вы вовремя статью подогнали, как раз скоро пакеты создавать. Спасибо.
В дополнение к статье, на недавней конференции от Luxoft рассказывали про проблемы с транзитивными зависимостями. Не поделитесь, на какие еще грабли можно наступить при работе с NuGet пакетами?
В дополнение к статье, на недавней конференции от Luxoft рассказывали про проблемы с транзитивными зависимостями. Не поделитесь, на какие еще грабли можно наступить при работе с NuGet пакетами?
Статья все-таки посвящена в большей степени автоматизации процесса сборки пакетов, а не работе с ними.
Тем не менее, в статье описаны пара проблем с которыми мы столкнулись:
1. Проблема использования одного проекта в нескольких солюшенах, которая связанная с тем, что после выполнения билда в VS, ссылки на сборки (в csproj-файле) будут указывать на тот каталог packages, который лежит рядом с запущенным солюшеном, и если эти изменения послать в TFS, то при билде другого солюшена, использующего проект, билд-сервер не сможет найти сборки, и будет ругаться.
2. Если требуется собирать пакет под разные версии .NET Framework, то придется потанцевать с бубном, настраивая конфигурации проектов, и даже поправить csproj-фалы ручками.
Как мы справляемся с этими проблемами в статье описано.
Из того, чего нет в статье, припоминаю некоторые проблемы с трансформациями конфигов приложений, в которые устанавливаются пакеты. Иногда при установке пакета перетирались уже существующие в конфиге секции. Но при решении таких проблем бубен не понадобится, нужно просто внимательно писать трансформации.
Других сколько-нибудь серьезных проблем пока не припоминаю.
Тем не менее, в статье описаны пара проблем с которыми мы столкнулись:
1. Проблема использования одного проекта в нескольких солюшенах, которая связанная с тем, что после выполнения билда в VS, ссылки на сборки (в csproj-файле) будут указывать на тот каталог packages, который лежит рядом с запущенным солюшеном, и если эти изменения послать в TFS, то при билде другого солюшена, использующего проект, билд-сервер не сможет найти сборки, и будет ругаться.
2. Если требуется собирать пакет под разные версии .NET Framework, то придется потанцевать с бубном, настраивая конфигурации проектов, и даже поправить csproj-фалы ручками.
Как мы справляемся с этими проблемами в статье описано.
Из того, чего нет в статье, припоминаю некоторые проблемы с трансформациями конфигов приложений, в которые устанавливаются пакеты. Иногда при установке пакета перетирались уже существующие в конфиге секции. Но при решении таких проблем бубен не понадобится, нужно просто внимательно писать трансформации.
Других сколько-нибудь серьезных проблем пока не припоминаю.
Оффтоп. Мне интересно, введут ли на nuget.org премодерацию или сделают когда-нибудь компиляцию только из исходных кодов? Я так понимаю, что абстрактный пакет
VasyaPupkin.MvcExtensions может сделать из моего сервера послушного зомби, а удобного способа быстро посмотреть исходники нет. Остаётся надеяться и верить в лучшее, но в эпоху скандалов информационной безопасности это как-то неправильно.
Интересная тема. Тем более, что средства разработки обычно работают под админом. WCF вообще не от админа сложно отлаживать.
Я обычно ищу пакет, затем внимательно изучаю автора — его сайт, комментарии к проекту, ищу статьи по использованию библиотеки. Конечно, в первую очередь это даёт представление о том, насколько его вообще удобно использовать и насколько он активно поддерживается. Но и некий элемент безопасности в этом присутствует.
На первый взгляд логично обязать выкладывать исходники и давать на них ссылку, но это не всегда возможно.
Вторая мысль — валидация самих разработчиков, подтверждение электронной почты, телефона, привязывание профиля OpenID. И выпиливание всех его разработок при обнаружении проблем.
Или может разделить источники на доверенные и не доверенные?
Я обычно ищу пакет, затем внимательно изучаю автора — его сайт, комментарии к проекту, ищу статьи по использованию библиотеки. Конечно, в первую очередь это даёт представление о том, насколько его вообще удобно использовать и насколько он активно поддерживается. Но и некий элемент безопасности в этом присутствует.
На первый взгляд логично обязать выкладывать исходники и давать на них ссылку, но это не всегда возможно.
Вторая мысль — валидация самих разработчиков, подтверждение электронной почты, телефона, привязывание профиля OpenID. И выпиливание всех его разработок при обнаружении проблем.
Или может разделить источники на доверенные и не доверенные?
Всегда можно декомпилировать исходники из либы dotPeek'ом или сразу решарпером.
Как правило, программисты, разглядев в соседнем проекте что-то полезное, первое время не заморачиваются — создают папку lib (dll, assemblies и т.п.) и складывают туда скомпилированные сборки из оригинального решения.
По поим наблюдением это делают когда владельцы библиотеки на нее малость подзабили и люди делают быстрый патч/пишут нужную фичу.
Или наоборот, в зависимую либу откатили в нугете, а часть нужной функциональности уже используется.
Потом просто люди забывают это удалить т.к. все работает. Могу даже пример дать :)
2. А почему не делаете пакет автоматически через AppVeyor при билде мастера?
Как-то так:
https://www.appveyor.com/docs/nuget#automatic-publishing-of-nuget-projects
А зачем отдельный PS скрипт если можно и pack и push в репозиторий сделать по Release AfterBuild прямо из MSBuild? Мне просто интересно с какой проблемой вы столкнулись. Мы, например, запихнули pdb прямо в пакет и убрали солюшен референсы полностью. Теперь солюшены при сборке деплоят пакеты и обновляют их с репозитория через тот же NuGet. В номер версию включен билдтайм, машины синхронизированы по общему NTP.
У меня вот несколько проектов используют один общий. Я выношу сейчас все в отдельный солюшн, со своим git-репозиторием. Затем из него собирается билд-машиной nuget-пакет, публикуется. Ну и потом обновляется версия в использующих пакет проектах.
Но одно меня гложет — очень неудобно будет в этот общий пакет добавлять функционал, проверяя его как-то отдельно. Хотелось бы иметь по-необходимости возможность работать с этим проектом как с обычным локальным — чтобы он был в солюшне, по нему работал дебаг, можно было бы менять что-то и проверять не прогоняя цикл push->publish nuget->update package.
Ничего по этой теме не подскажете? Т.е. хочется по необходимости получать упрощенный цикл разработки — как он был бы если это был просто проект в солюшне, но при этом иметь отдельный репозиторий и nuget для случаев когда такое не нужно.
Я пока думаю временно подключать проект в студию, и настраивать ему output прямо в packages/myproject. Должно сработать, но как-то кривовато.
Но одно меня гложет — очень неудобно будет в этот общий пакет добавлять функционал, проверяя его как-то отдельно. Хотелось бы иметь по-необходимости возможность работать с этим проектом как с обычным локальным — чтобы он был в солюшне, по нему работал дебаг, можно было бы менять что-то и проверять не прогоняя цикл push->publish nuget->update package.
Ничего по этой теме не подскажете? Т.е. хочется по необходимости получать упрощенный цикл разработки — как он был бы если это был просто проект в солюшне, но при этом иметь отдельный репозиторий и nuget для случаев когда такое не нужно.
Я пока думаю временно подключать проект в студию, и настраивать ему output прямо в packages/myproject. Должно сработать, но как-то кривовато.
Из вашего описания не ясно, зачем вам NuGet пакет. Я правильно понял, у вас есть один Solution, в котором несколько проектов (Projects) и выхотите один из них хранить отдельно? Он где-нибудь кроме этого solution используется? Из этого солюшена вы собираете несколько приложений или одно?
Сейчас есть несколько солюшнов, в каждом из которых есть проект с инфраструктурными штуками, которые нужны всем солюшнам. Доселе изменения в нем переносились туда-сюда копированием. Сейчас я этот проект выношу в nuget-пакет.
И мне вот интересно как при этом не потерять возможность удобно что-то допиливать в этом общем проекте в контексте одного из солюшнов.
Ну, скажем, хочу я условный хелпер ToColoredHTMLString написать. Мне было бы удобнее как-то подключить на время этот общий проект в один из солюшнов, написать там этот хелпер, сразу его попробовать использовать — допилить где-то, отладиться, посмотреть как оно на UI выглядит. И уже потом — залить общий проект в git, запаблишить в nuget, обновить nuget пакет в солюшне, и влить этот солюшн в другой git. А потом как-нибудь обновить пакет в других солюшнах.
Без подключения в солюшн на время, я буду ограничен разработкой на тестах, что не всегда достаточно.
И мне вот интересно как при этом не потерять возможность удобно что-то допиливать в этом общем проекте в контексте одного из солюшнов.
Ну, скажем, хочу я условный хелпер ToColoredHTMLString написать. Мне было бы удобнее как-то подключить на время этот общий проект в один из солюшнов, написать там этот хелпер, сразу его попробовать использовать — допилить где-то, отладиться, посмотреть как оно на UI выглядит. И уже потом — залить общий проект в git, запаблишить в nuget, обновить nuget пакет в солюшне, и влить этот солюшн в другой git. А потом как-нибудь обновить пакет в других солюшнах.
Без подключения в солюшн на время, я буду ограничен разработкой на тестах, что не всегда достаточно.
Ага, теперь понятнее. На самом деле, у вас не так уж и много вариантов. Мы у себя подобные вещи помечаем в коде, как кандидаты на перенос в общую библиотеку. Дальше, если код стабилен, то вливаем его в репозиторий из которого билдится nuget пакет. Не так уж часто одинаковый код нужен сразу сейчас и везде. Обычно есть что-то, что уже работает в одном проекте и хочется переиспользовать в другом.
В торой варинт — это иметь тестовое приложение в солюшне с общей библиотекой.
В торой варинт — это иметь тестовое приложение в солюшне с общей библиотекой.
Да, эти два варианта тоже планирую использовать:
— заведу в каждом солюшне проект типа Xyz.Common.Staging, код из которого будет перетекать в nuget-пакет
— в репозитории для nuget уже есть тесты, но видимо придется создать и тестовый веб-проект — не все можно нормально проверить и отладить на тестах
По-идее этого должно хватить. На крайняк — остается вариант временно настроить outDir общего проекта прямо в packages конкретного.
— заведу в каждом солюшне проект типа Xyz.Common.Staging, код из которого будет перетекать в nuget-пакет
— в репозитории для nuget уже есть тесты, но видимо придется создать и тестовый веб-проект — не все можно нормально проверить и отладить на тестах
По-идее этого должно хватить. На крайняк — остается вариант временно настроить outDir общего проекта прямо в packages конкретного.
Добавлю что в рамках одной компании очень удобно использовать TeamCity как приватный Nuget Feed и Symbol Server. Так что после удачной сборки, ваши пакеты будут автоматически обновлены.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Автоматизированное создание NuGet-пакетов