Многофункциональная сборка 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 нет никакого способа выяснить, где взять все исходные файлы, и я не вижу никакой документации о том, как это сделать, используя соглашения о каталогах. или.
Итак, мои вопросы:
Есть ли способ добавить исходные файлы в пакет на основе соглашения?Есть ли способ дважды упаковать пакет на основе проекта с разными идентификаторами?Есть ли другой путь, который, возможно, я не рассматривал?Любые мысли будут высоко ценится.