Есть ли рекомендуемый подход к настройке пакета NuGet, нацеленного на несколько фреймворков в TeamCity с использованием MSBuild?

Я прочитал несколько сообщений (см. ссылки ниже) и еще не нашел руководства по передовым практикам, характерным для моего технологического стека.

Цель: Создать единый пакет NuGet, ориентированный на несколько .NET-фреймворков, построенных из одного файла .csproj через TeamCity с использованием MSBuild и NuGet.

Ограничения:

Вытяните код из VCS только один раз.
Все скомпилированные сборки должны быть одинаковыми версиями.
Одиночный .csproj(не один для каждой целевой структуры).

У меня есть два подхода:

Создайте конфигурацию единой сборки. Он будет содержать три этапа сборки: компилировать .NET 3.5, компилировать .NET 4.0, пакет с NuGet. Каждый шаг сборки будет зависеть от успеха последнего. Единственная реальная проблема, которую я вижу при таком подходе (и, надеюсь, там есть решение, о котором я не знаю) состоит в том, что для каждого шага сборки потребуется собственный набор параметров построения (например, system.TargetFrameworkVersion и system.OutputPath) для обозначения уникальное место для размещения DLL (например, bin\release\v3.5 и bin\release\v4.0), чтобы шаг пакета NuGet мог выполнять свою работу на основе раздела Files в файле .nuspec.
Создайте несколько конфигураций сборки. Одна конфигурация сборки на шагах сборки, описанных выше. При таком подходе легко решить проблемы с параметрами сборки TargetFrameworkVersion и OutputPath, но теперь мне нужно создавать зависимости моментальных снимков и делиться номером версии сборки в сборках. Он также питается слотами конфигурации, которые подходят (но не оптимальны) для нас, поскольку у нас есть лицензия Enterprise.

Вариант №1 кажется очевидным выбором. Варианты № 2 чувствуют себя грязными.

Итак, мои два вопроса:

Можно ли создавать параметры, которые являются уникальными для этапа сборки?
Есть ли третий, лучший подход?

Литература:

Ответ 1

Вот мое предпочтительное решение (вариант №1):

Магия полагается на неудачное обходное решение. Если вы готовы пойти на этот компромисс, это решение действительно работает. Если вы этого не сделаете, вы можете следить за проблемой, которую я открыл на трекере проблем JetBrains.

Конфигурация одиночной сборки выглядит следующим образом:

Обратите внимание на имя первых двух шагов сборки. Фактически, они явно называются значениями TargetFrameworkVersion для .NET 3.5 и 4.0 соответственно.

Затем в разделе "Параметры сборки" я настроил следующие параметры:

И, наконец, шаг Nuget Pack выполняет перевод пути файла в соответствии с моим разделом файлов .nuspec:

<files>
    <file src="bin\release\v3.5\*.*" target="lib\net35" />
    <file src="bin\release\v4.0\*.*" target="lib\net40" />
</files>

Ответ 2

Вот решение, использующее второй подход:

Проект содержит следующие конфигурации и шаблон сборки:

Генератор генераторов общих разделов - это первая сборка в цепочке. Он ничего не делает, кроме как создать номер сборки, с которым будут делиться зависимые сборки. Я использую подключенный TeamCity плагин Shared Build Number от Николаса Уильямса.

И вот заметные конфигурации в шаблоне сборки:

Обратите внимание, что номер сборки поступает из идентификатора сборки генератора общих общих номеров, упомянутого выше. Таким образом, в моем случае этот идентификатор сборки равен 14. Также обратите внимание на переменную% TargetFrameworkVersion% в пути артефакта. К счастью, TeamCity поддерживает переменную интерполяцию почти везде.

Чтобы шаблон мог использовать номер сборки, он должен иметь зависимость моментального снимка от этой конфигурации сборки:

И, наконец (относительно шаблона), параметры сборки почти идентичны параметрам в моем предпочтительном решении. Однако обратите внимание на дополнительный параметр конфигурации. Это будет зависеть от наследующих конфигураций сборки:

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

И, конечно же, вам нужно установить реальную целевую структуру:

С настроенными настройками сборки теперь вы можете настроить конфигурацию сборки пакета NuGet. Вам не нужно прикреплять к корню VCS:

Но вам нужно настроить множество зависимостей (как моментальный снимок, так и артефакт):

И, наконец, все готово.