Многострочная структура NuGet с символами для управления внутренней зависимостью

Возможно, я нажимаю конверт здесь, но я отчаянно пытаюсь использовать NuGet, чтобы облегчить аддон DLL, в котором я оказался.

У нас есть 4 основных продукта, которые все живут во взаимосвязанных хранилищах Mercurial. Все они "разделяют" 3 основных сборки, а затем все остальное в значительной степени зависит от продукта. Теперь стало очень сложно управлять, потому что один продукт был обновлен до .NET 4.0 и использует внешние зависимости, которые требуют .NET 4.0, а другой продукт застрял в .NET 3.5 по причинам, по которым я даже не хочу входить.

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

Чтобы исправить это, я хочу вытащить 3 основные сборки и превратить их в свой собственный проект с их собственным циклом выпуска и позаботиться о том, чтобы они могли компилироваться как с .NET 3.5, так и с 4.0, а затем превратите их в пакеты NuGet, содержащие несколько версий фреймворка.

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

Итак, я настроил частный сервер NuGet и закрытый сервер SymbolSource. Затем я тщательно объединил все изменения со всеми репозиториями и выбросил все, кроме моих основных сборок. Затем я тщательно отредактировал файлы .csproj вручную, чтобы вместо платформы AnyCPU каждый проект имел целевые платформы 3.5 и 4.0, которые задают условные константы (для управления особенностями платформы, такие как System.Dynamic), и устанавливает версию фреймворка.

Затем я установил конфигурации решений для "3.5 Debug", "3.5 Release", "4.0 Debug" и "4.0 Release". Каждый из них предназначен для соответствующей конфигурации (отладка или выпуск) и платформы (3.5 или 4.0).

Я могу создать все в Visual Studio для любой платформы. Теперь у меня есть проблема, когда дело доходит до NuGet, потому что есть два способа создать пакет, и у обоих есть слабость, если я не пропущу что-то:

Пакет по файлу проекта

nuget pack MyProject.csproj -Build -Symbols -Version <insert-from-build-server> -Properties "Configuration=Release;Platform=3.5;"

Проблемы с этим:

В то время как версия 3.5 построена и упакована, на выходе написано "Построение проекта для целевой среды".NETFramework, версия = v4.0 ".
Если я распакую результирующие пакеты, сборки находятся под lib\net40, что неверно.
Я не думаю, что есть какой-либо способ разместить 2 рамочных объекта таким образом, вы должны сделать это другим способом с папками и соглашениями.
Я согласен с тем, что вы не можете скомпилировать фреймворки вместе и сделать 2 пакета под названием MyProject (которые я буду делать как 4.0) и MyProject.V35... однако я не могу понять, как иметь одинаковые проекта и nuspec и заканчиваются двумя разными результатами с разными идентификаторами.

Пакет по файлу Nuspec

С помощью этого метода я должен сам выполнить все mysbuilding, а затем выполнить кучу копирования файлов, чтобы настроить структуру папок, например

* MyProject.nuspec
* net40
    * MyProject.dll
    * MyProject.pdb
* net35
    * MyProject.dll
    * MyProject.pdb

Тогда я могу запустить nuget pack MyProject.nuspec, но тогда нет никакого источника, чтобы идти с символами, потому что без файла .csproj у NuGet нет способа выяснить, где получить все исходные файлы, и я не вижу любая документация о том, как это сделать, используя соглашения о каталогах.

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

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

Любые мысли будут высоко оценены.

Ответ 1

Ответ Ксавьера привел меня в правильном направлении, а также сообщил о поиске в Google. Я не был полностью осведомлен о объявлениях файлов, и при поиске по этим строкам я нашел сообщение Джошуа Фланагана Советы по созданию пакетов NuGet, который отлично. Ксавье и Джошуа вместе научили меня нескольким вещам:

Для сборки пакета вам не нужно собирать дерево, соответствующее стандартным файлам. Гораздо лучше использовать элемент файла для выбора файлов и нацеливать их на целевой каталог в собранном пакете NuGet.
Флаг NuGet -Symbols не просто работает для упаковки в файле .csproj. Когда вы используете его в файле .csproj, то убедитесь, что он определяет, как упаковывать все исходные файлы. Но вы также можете использовать -Symbols в файле .nuspec, который включает источник через элементы файла. Обычный пакет NuGet не будет включать каталог src, но пакет Symbols будет.

Итак, позвольте мне описать мой процесс сборки, как это происходит на моем CI-сервере:

Создайте решение с помощью конфигурации решения "3.5 Release".
Создайте решение с помощью конфигурации решения "4.0 Release".
Используйте ILMerge.exe для интернализации некоторых сборок. У меня есть эти выходные данные (например) bin\Release-3.5\merged, поэтому мне не нужно обезьяны с переименованием целевой сборки в temp.dll, прежде чем использовать ее в слиянии.
Создайте пакет с помощью .nuspec в Powershell.

Вот команда пакета:

nuget pack src\MyProject\MyProject.nuspec -OutputDirectory .\output -Build -Symbols -Version $Version

Обратите внимание, что $Version передается с сервера сборки, поэтому я могу использовать его номер сборки в качестве последней части версии.

Вот файл .nuspec:

<?xml version="1.0"?>
<package>
    <metadata>
        <id>MyProject</id>
        <version>0.0.0</version>
        <title>MyProject</title>
        <authors>David Boike</authors>
        <owners>David Boike</owners>
        <requireLicenseAcceptance>false</requireLicenseAcceptance>
        <description>MyProject</description>
        <releaseNotes></releaseNotes>
        <copyright>Copyright 2012</copyright>
        <tags>my tags</tags>
    </metadata>
    <files>
        <file src="bin\Release-4.0\merged\MyProject.dll" target="lib\net40" />
        <file src="bin\Release-4.0\merged\MyProject.pdb" target="lib\net40" />
        <file src="bin\Release-4.0\MyProject.xml" target="lib\net40" />
        <file src="bin\Release-3.5\merged\MyProject.dll" target="lib\net35" />
        <file src="bin\Release-3.5\merged\MyProject.pdb" target="lib\net35" />
        <file src="bin\Release-3.5\MyProject.xml" target="lib\net35" />
        <file src="**\*.cs" target="src" />
    </files>
</package>

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

Результатом является пакет для моего личного сервера NuGet, который содержит документацию DLL, PDB и XML для сборки для .NET 3.5 и 4.0, а затем отдельный пакет символов для моего личного SymbolServer, который включает в себя все вышеперечисленное плюс источник. Это очень легко просмотреть с помощью NuGet Package Explorer, который я рекомендую вам высоко.

Наконец, я протестировал все и с помощью настройки Visual Studio, предложенной на symbolource.org (за исключением моего собственного личного сервера символов), я был способный отлаживать код и легко входить в исходный код.

Еще раз спасибо Ксавье за то, что он провел меня по правильному пути!

Ответ 2

Вы знаете, что есть третий вариант? При таргетинге на файл csproj он также ищет файл nuspec с тем же именем, что и файл вашего проекта (myProject.csproj → myProject.nuspec). Это означает, что вы можете добавить дополнительные метаданные к результирующему пакету, указав его в файл nuspec, в то же время нацелив на свой файл csproj. По сути, вы получите пакет, содержащий объединенные метаданные из файла csproj и файла nuspec.

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

Я бы посоветовал вам создать два проекта, один таргетинг NET35, другой, предназначенный для NET40, и добавление файлов в качестве ссылок в один из проектов. Таким образом, вы можете создавать оба проекта и упаковывать весь вывод в один пакет NuGet с помощью файла nuspec.

Теперь, что касается символов, я думаю, что у вас может быть второй файл nuspec (например, myProject.symbols.nuspec), где вы можете добавить все содержимое проекта (источники и т.д.) с помощью подстановочных знаков, аналогично тому, что показано ниже.

<file src="myProject35\**\*.cs" target="src" />
<file src="myProject40\bin\Release\*.dll" target="lib\net40" />
<file src="myProject40\bin\Release\*.pdb" target="lib\net40" />
<file src="myProject35\bin\Release\*.dll" target="lib\net35" />
<file src="myProject35\bin\Release\*.pdb" target="lib\net35" />

Надеюсь, это поможет или, по крайней мере, предоставит вам некоторую информацию, чтобы найти выход:)

Cheers, Xavier

Ответ 3

Ознакомьтесь с новыми функциями в NuGet 2.5, связанными с зависимыми от версии версиями версиями: http://docs.nuget.org/docs/release-notes/nuget-2.5

Возможно, вам понадобится использовать конфигурации компоновки с условными элементами ссылок в файлах csproj (conditinal на TargetFrameworkVersion), затем запустите свою сборку во всех конфигурациях и создайте выходные данные для net35 и net40 с дополнительным таргетингом ссылок в ваш nupkg.