Вопрос по nuget, multiplatform, nuget-package – Многофункциональная сборка NuGet с символами для управления внутренними зависимостями

20

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

У нас есть 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 Отладка ","3.5 Выпуск ","4.0 Debug », а также "4.0 Release ", Каждый из них нацелен на соответствующую конфигурацию (отладка или выпуск) и платформу (3.5 или 4.0).

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

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

nuget pack MyProject.csproj -Build -Symbols -Version  -Properties "Configuration=Release;Platform=3.5;"

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

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

Пакет по Nuspec File

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

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

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

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

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

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

Все мои возражения - возьми их! Просто возьми их! Cristi Diaconescu

Ваш Ответ

3   ответа
15

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

Ты неЧтобы собрать пакет, нужно собрать дерево файлов, соответствующее соглашениям. Это'Гораздо лучше использовать элемент file для выбора файлов и нацеливания их на каталог назначения в собранном пакете NuGet.NuGet»Флаг s-символов не делаетt просто работать для упаковки в файл .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.

Вот команда package:

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

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

Вот файл .nuspec:



    
        MyProject
        0.0.0
        MyProject
        David Boike
        David Boike
        false
        MyProject
        
        Copyright 2012
        my tags
    
    
        
        
        
        
        
        
        
    

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

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

Наконец, я проверил все и сНастройка Visual Studio предлагается на символах.орг (кроме моего личного сервера символов) я смог отладить код и легко перейти к исходному коду.

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

0

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

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

8

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

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

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

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






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

Ура, Ксавье

Я действительно ДЕЙСТВИТЕЛЬНО неЯ не хочу поддерживать два отдельных файла csproj. Но ваш ответ привел меня к возможному решению. Спасибо + upvote! David Boike
Я думаю, что для создания пакетов .nuget, которые поддерживают netstandard и полноценный фреймворк, это лучший вариант. Я нене думаю, что @DavidBoike 'ответ будет работать. pomeroy
@pomeroy Новый формат csproj может обрабатывать шаблоны глобальных файлов, т.е. <Compile Include = "***. cs "/> а не строка для каждого файла. Намного проще иметь 2 файла csproj, которые содержат (в основном) один и тот же набор файлов, но строят их по-разному.natemcmaster.com/blog/2017/03/09/vs2015-to-vs2017-upgrade/... David Boike
Когда вы советуете создать два проекта, говорите ли вы MyProject.v35.csproj и MyProject.v40.csproj со всеми файлами .cs, на которые есть ссылки в обоих? Проекты содержат много файлов с кодами, и я действительно надеялся избежать кошмара управления по их синхронизации. David Boike

Похожие вопросы