2016-10-14 5 views
1

Я делаю обновления для целевых версий проектов .NET Framework, обновляющихся до последней версии .NET (4.6.2).Создание пакета TeamCity NuGet для разных .NET-платформ

Некоторые из этих проектов представляют собой пакеты NuGet, созданные в TeamCity 9.0.2.

Я использую шаги в руководстве для создания нескольких конфигураций сборки для другой версии .NET Framework, так как некоторые из проектов, которые я не обновил до 4.6.2, ссылаются на пакеты NuGet. Поэтому я пытаюсь заставить TeamCity использовать эти конфигурации сборки для вывода различных версий Net40, Net45, Net46 и Net462, чтобы иметь полную совместимость, не требуя обновления всех проектов, которые используют NuGet при обновлении пакетов.

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

Current Build Steps

Так одна вещь, которую я попробовал, что я думаю, что нужно делать, но я не уверен, что будет дублировать первый шаг сборки и установите Configuration в Release-Net46. Я думаю, что это необходимо, иначе эта версия сборки не будет построена (пожалуйста, поправьте меня, если я ошибаюсь!)

Вторая вещь, которую я пробовал, - это дублировать шаг NuGet Pack и в Properties set Configuration=Release-Net46, но все, что было сделано, заменило Net462 версию Net46 и не включало оба в артефакты, как я надеялся.

Я также попытался в Properties из NuGet Pack иметь несколько Configuration элементов, таких как Configuration=Release;Configuration=Release-Net46 или Configuration=Release,Release-Net46, но и те, кто в результате сборки провала так ясно, что это не ответ.

NuGet Pack Properties

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

Возможно ли это? Я подумал о создании отдельных проектов для каждой конфигурации сборки в TeamCity, но я не уверен, что это правильный путь или это может вызвать проблемы с фидом пакетов, и было бы неоправданно дублировать проект четыре раза для каждой версии .NET Framework ,

ответ

1

Хорошо, я в конечном итоге решил это путем проб и ошибок и узнал о NuSpec. Заметьте, я не нашел способ сделать это, используя только настройки TeamCity, но это одинаково хорошо.

Я был прав, что вам нужны дополнительные шаги сборки для сборки сборок в конфигурациях сборки уровня решения/уровня проекта и укажите каждый Configuration по адресу Release-NetX.

TeamCity Build Steps

EDIT Я нашел это на самом деле лучше в выше, чтобы указать NetX построить шаги на .csproj, а не .sln. Таким образом, вам не нужны конфигурации сборки на уровне решения, если они существуют в .csproj, тогда все будет хорошо.

Как только это будет сделано, TC будет строить все версии в своих соответствующих каталогах bin\Release-NetX.

Далее следует добавить файл .nuspec в корневую директорию проекта решения, чтобы построить NuGet for.

<?xml version="1.0"?> 
<package xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> 
    <metadata xmlns="http://schemas.microsoft.com/packaging/2010/07/nuspec.xsd"> 
    <id>Foo.Bar.Package</id> 
    <version>1.0.23</version> 
    <authors>FooBar Industries</authors> 
    <requireLicenseAcceptance>false</requireLicenseAcceptance> 
    <description>FooBar Industries package</description> 
    </metadata> 
    <files> 
    <file src="bin\Release\*.dll" target="lib\net462" /> 
    <file src="bin\Release-Net46\*.dll" target="lib\net46" /> 
    <file src="bin\Release-Net45\*.dll" target="lib\net45" /> 
    <file src="bin\Release-Net4\*.dll" target="lib\net40" /> 
    </files> 
</package> 

Далее следует изменить NuGet Pack Teamcity сборки Шаг и в Specification files разделе и указать это в файл .nuspec. Есть флажок для Prefer project files to .nuspec. Это сработало для меня, просто сняв флажок, и мне даже не нужно указывать на файл .nuspec.

TeamCity NuGet Pack build step

Затем на запуск сборки, все версии выводятся и будут доступны для использования без обновления всех проектов, которые ссылаются на этот пакет.

enter image description here

+1

Прохладный раствор! Но как насчет тестов? Кажется, что только конфигурация «Release» будет протестирована в подстановочном знаке, содержащем подстроку «Release». Как насчет тестирования сборок в папках «Release-Net46» и других? – Alex141

+1

Вы поднимаете отличную точку, вам нужно будет создать повторяющиеся шаги NUnit для каждого набора тестов. Который должен быть указан в bin \ Release-NetX различных конфигураций сборки. Честно говоря, мне нужны только разные версии каркаса, предназначенные для таргетинга в других проектах, и я не думал расширять модульные тесты для использования каждой версии. Хорошее мышление! –

Смежные вопросы