Многофункциональная сборка 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, Version = v4.0».Если я распаковываю полученные пакеты, сборки находятся подlib\net40 что неправильно.Я не думаю, что есть какой-либо способ упаковать 2 целевых фреймворка таким образом, вы должны сделать это другим способом с папками и соглашениями.Я готов согласиться с тем, что вы не можете упаковать фреймворки вместе и сделать 2 пакета под названием MyProject (что я бы сделал как 4.0) и MyProject.V35 ... однако я не могу понять, как создать один и тот же проект и nuspec. и получить 2 разных результата с разными идентификаторами.

Пакет по Nuspec File

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

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

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

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

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

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

Ответы на вопрос(3)

Ваш ответ на вопрос