Заметки о выпуске NuGet 2.5
Заметки | о выпуске NuGet 2.2.1
NuGet 2.5 выпущен 25 апреля 2013 года. Этот выпуск был настолько большим, мы чувствовали себя вынужденными пропустить версии 2.3 и 2.4! На сегодняшний день это самый большой выпуск, который у нас был для NuGet, с более чем [160 work items](https://nuget.codeplex.com/workitem/list/advanced?release=NuGet%202.5&status=all)
в выпуске.
Мы хотели бы поблагодарить следующие внешние участник за их значительный вклад в NuGet 2.5:
[Daniel Plaisted](https://www.codeplex.com/site/users/view/dsplaisted)
(@dsplaisted)[#2847](https://nuget.codeplex.com/workitem/2847)
— добавьте MonoAndroid, MonoTouch и MonoMac в список известных идентификаторов целевой платформы.
[Andres G. Aragoneses](https://www.codeplex.com/site/users/view/knocte)
(@knocte)[#2865](https://nuget.codeplex.com/workitem/2865)
— ИсправлениеNuGet.targets
орфографии для ОС с учетом регистра
[David Fowler](https://www.codeplex.com/site/users/view/dfowler)
(@davidfowl)- Сделайте решение сборкой на Mono.
[Andrew Theken](https://www.codeplex.com/site/users/view/atheken)
(@atheken)- Исправление сбоя модульных тестов в Mono.
[Olivier Dagenais](https://www.codeplex.com/site/users/view/OliIsCool)
(@OliIsCool)[#2920](https://nuget.codeplex.com/workitem/2920)
— команда пакета nuget.exe не распространяет свойства в MSBuild
[Miroslav Bajtos](https://www.codeplex.com/site/users/view/MiroslavBajtos)
(@bajtos)[#1511](https://nuget.codeplex.com/workitem/1511)
— Изменен код обработки XML для сохранения форматирования.
[Adam Ralph](http://www.codeplex.com/site/users/view/adamralph)
(@adamralph)- Добавлены распознанные слова в пользовательский словарь, чтобы разрешить build.cmd успешно.
[Bruno Roggeri](https://www.codeplex.com/site/users/view/broggeri)
- Исправление модульных тестов при запуске в локализованной среде VS.
[Gareth Evans](https://www.codeplex.com/site/users/view/garethevans)
- Извлеченный интерфейс из PackageService
[Maxime Brugidou](https://www.codeplex.com/site/users/view/brugidou)
(@brugidou)[#936](https://nuget.codeplex.com/workitem/936)
— обработка зависимостей проекта при упаковке
[Xavier Decoster](https://www.codeplex.com/site/users/view/XavierDecoster)
(@XavierDecoster)[#2991](https://nuget.codeplex.com/workitem/2991)
,[#3164](https://nuget.codeplex.com/workitem/3164)
— поддержка очистки текстового пароля при хранении учетных данных источника пакета в файлах nuget.cofig
[James Manning](http://www.codeplex.com/site/users/view/jmanning)
(@manningj)[#3190](http://nuget.codeplex.com/workitem/3190)
,[#3191](https://nuget.codeplex.com/workitem/3191)
— исправление описания справки get-Package
Мы также ценим следующих лиц для поиска ошибок с NuGet 2.5 beta/RC, которые были утверждены и исправлены до окончательного выпуска:
[Tony Wall](https://www.codeplex.com/site/users/view/CodeChief)
(@CodeChief)[#3200](https://nuget.codeplex.com/workitem/3200)
— MSTest сбой с последними сборками NuGet 2.4 и 2.5
Одной из самых запрошенных функций всех времен была возможность перезаписать файлы содержимого, которые уже существуют на диске при включении в пакет NuGet. Начиная с NuGet 2.5 эти конфликты определяются, и вам предлагается перезаписать файлы, в то время как ранее эти файлы всегда пропускались.
"nuget.exe обновление" и "Install-Package" теперь имеют новый параметр "-FileConflictAction", чтобы задать некоторые сценарии командной строки по умолчанию.
Задайте действие по умолчанию, если файл из пакета уже существует в целевом проекте. Установите значение Overwrite, чтобы всегда перезаписать файлы. Установите значение "Игнорировать", чтобы пропустить файлы. Если он не указан, запросит каждый конфликтующий файл.
Новая обычная папка создана на верхнем уровне пакета NuGet. В качестве однорангового узла \lib
\content
и \tools
теперь можно включить папку \build
в пакет. В этой папке можно поместить два файла с фиксированными именами {packageid}.targets
или {packageid}.props
. Эти два файла могут быть либо непосредственно в build
папках, относящихся к платформе, так же как и к другим папкам. Правило выбора оптимальной папки платформы совпадает с тем же правилом, что и в этих папках.
Когда NuGet устанавливает пакет с файлами сборки, он добавит элемент MSBuild <Import>
в файл проекта, указывающий на .targets
файлы и .props
файлы. Файл .props
добавляется вверху, а .targets
файл добавляется в нижней части.
До версии 2.5 в .nuspec
файле пользователь может указать только ссылочные файлы, которые будут добавлены для всех платформ. Теперь с помощью этой новой функции в версии 2.5 пользователь может создать <reference/>
элемент для каждой поддерживаемой платформы, например:
<references>
<group targetFramework="net45">
<reference file="a.dll" />
</group>
<group targetFramework="netcore45">
<reference file="b.dll" />
</group>
<group>
<reference file="c.dll" />
</group>
</references>
Ниже приведен поток добавления ссылок NuGet на проекты на .nuspec
основе файла:
lib
Найдите папку, подходящую для целевой платформы, и получите список сборок из этой папки.- Отдельно найдите группу ссылок, подходящую для целевой платформы, и получите список сборок из этой группы. Эталонная группа без указанной целевой платформы — это резервная группа.
- Найдите пересечение двух списков и используйте их в качестве ссылок для добавления
Эта новая функция позволит авторам пакетов использовать функцию "Ссылки" для применения подмножества сборок к разным платформам, если в противном случае потребуется переносить повторяющиеся сборки в нескольких lib
папках.
Примечание. В настоящее время для использования этой функции необходимо использовать пакет nuget.exe; Пакет NuGet Обозреватель пока не поддерживает его.
Многие из вас знают о командлете PowerShell "Update-Package" для обновления всех пакетов; Теперь есть простой способ сделать это через пользовательский интерфейс, а также.
Чтобы попробовать эту функцию, выполните указанные ниже действия.
- Создание приложения ASP.NET MVC
- Запуск диалогового окна "Управление пакетами NuGet"
- Выберите "Обновления"
- Нажмите кнопку "Обновить все"
Теперь nuget.exe командный пакет обрабатывает ссылки на проекты со следующими правилами:
- Если в упоминаемом проекте есть соответствующий
.nuspec
файл, например файл, вызываемыйproj1.nuspec
в той же папке, чтоproj1.csproj
и в ней, этот проект добавляется в качестве зависимостей для пакета, используя идентификатор и версию, считываемые из.nuspec
файла. - В противном случае файлы указанного проекта упаковываются в пакет. Затем проекты, на которые ссылается этот проект, будут обрабатываться с помощью тех же правил рекурсивно.
- Добавляются все библиотеки DLL
.pdb
и.exe
файлы. - Добавляются все остальные файлы содержимого.
- Все зависимости объединяются.
Это позволяет ссылаться на проект как зависимость, если файл существует .nuspec
, в противном случае он становится частью пакета.
Дополнительные сведения см. здесь: [http://nuget.codeplex.com/workitem/936](http://nuget.codeplex.com/workitem/936)
Новый атрибут метаданных с именем minClientVersion теперь может указывать минимальную версию клиента NuGet, необходимую для использования пакета.
Эта функция помогает автору пакета указать, что пакет будет работать только после определенной версии NuGet. Так как новые .nuspec
функции добавляются после NuGet 2.5, пакеты смогут претендовать на минимальную версию NuGet.
<metadata minClientVersion="2.6">
Если у пользователя установлен NuGet 2.5, а пакет определяется как требование 2.6, визуальные подсказки будут предоставлены пользователю, указывающим, что пакет не будет установлен. Затем пользователь сможет обновить свою версию NuGet.
Это улучшит существующий интерфейс, в котором пакеты начинают устанавливаться, но затем завершаются сбоем, указывающим на нераспознанную версию схемы.
Перед установкой Пакета NuGet 2.5, который зависит от пакета, уже установленного в проекте, зависимость будет обновлена в рамках новой установки, даже если существующая версия удовлетворяет зависимости.
Начиная с NuGet 2.5, если версия зависимостей уже удовлетворена, зависимость не будет обновлена во время других установок пакета.
Сценарий:
- Исходный репозиторий содержит пакет B с версией 1.0.0 и 1.0.2. Он также содержит пакет A, который имеет зависимость от B (>= 1.0.0).
- Предположим, что текущий проект уже установлен пакет B версии 1.0.0. Теперь необходимо установить пакет A.
В NuGet 2.2 и более ранних версиях:
- При установке пакета A NuGet автоматически обновит B до версии 1.0.2, несмотря на то что существующая версия 1.0.0 уже удовлетворяет ограничению версии зависимостей, то есть = >1.0.0.
В NuGet 2.5 и более поздней версии:
- NuGet больше не обновляет B, так как обнаруживает, что существующая версия 1.0.0 удовлетворяет ограничению версии зависимостей.
Дополнительные сведения об этом изменении см. в подробных [work item](https://nuget.codeplex.com/workitem/1681)
сведениях, а также о связанных [discussion thread](https://nuget.codeplex.com/discussions/436712)
.
Если вы устраняете неполадки nuget.exe или просто интересно, какие HTTP-запросы выполняются во время операций, переключатель "подробное описание" теперь выводит все HTTP-запросы.
Прежде чем NuGet 2.5, если вы попытались запустить "nuget.exe push" в источник пакета на основе пути UNC или локальной папки, отправка завершится ошибкой. Благодаря недавно добавленной функции иерархической конфигурации она стала распространенной для nuget.exe, чтобы выбрать источник UNC/folder или коллекцию NuGet на основе HTTP.
Начиная с NuGet 2.5, если nuget.exe идентифицирует источник UNC/folder, он выполнит копирование файла в источник.
Следующая команда теперь будет работать:
nuget push -source \\mycompany\repo\ mypackage.1.0.0.nupkg
команды nuget.exe, которые получают доступ к конфигурации (все, кроме spec и pack), теперь поддерживают новый параметр -ConfigFile, который заставляет конкретный файл конфигурации использоваться вместо файла конфигурации по умолчанию в %AppData%\nuget\Nuget.Config.
Пример:
nuget sources add -name test -source http://test -ConfigFile C:\test\.nuget\Nuget.Config
С помощью NuGet 2.5 средство NuGet теперь доступно для собственных проектов в Visual Studio. Мы ожидаем, что большинство собственных пакетов будут использовать функцию импорта MSBuild выше, используя средство, созданное проектом CoApp. Дополнительные сведения см . на веб-сайте coapp.org.
Имя целевой платформы "native" представлено для пакетов для включения файлов в \build, \content и \tools при установке пакета в собственный проект. Папка lib не используется для собственных проектов.