Заметки о выпуске NuGet 2.1

Заметки | о выпуске NuGet 2.0 NuGet 2.2

NuGet 2.1 выпущен 4 октября 2012 года.

Иерархическая конфигурация Nuget.Config

NuGet 2.1 обеспечивает большую гибкость в управлении параметрами NuGet путем рекурсивного перемещения по структуре NuGet.Config папок поиска файлов, а затем сборки конфигурации из набора всех найденных файлов. В качестве примера рассмотрим сценарий, в котором команда имеет внутренний репозиторий пакетов для сборок CI других внутренних зависимостей. Структура папок для отдельного проекта может выглядеть следующим образом:

C:\
C:\myteam\
C:\myteam\solution1
C:\myteam\solution1\project1

Кроме того, если для решения включено восстановление пакета, то в следующей папке также будет существовать:

C:\myteam\solution1\.nuget

Чтобы внутренний репозиторий пакетов группы был доступен для всех проектов, над которыми работает команда, не делая его доступным для каждого проекта на компьютере, мы можем создать новый файл Nuget.Config и поместить его в папку c:\myteam. Невозможно указать папку пакетов для каждого проекта.

<configuration>
    <packageSources>
    <add key="Official project team source" value="http://teamserver/api/v2/" />
    </packageSources>
    <disabledPackageSources />
    <activePackageSource>
    <add key="Official project team source" value="http://teamserver/api/v2/" />
    </activePackageSource>
</configuration>

Теперь можно увидеть, что источник был добавлен, выполнив команду "nuget.exe источников" из любой папки под C:\myteam, как показано ниже:

NuGet.Config Файлы выполняются в следующем порядке:

1. .nuget\Nuget.Config
2. Рекурсивный переход из папки проекта в корневой
3. Глобальный Nuget.Config (%appdata%\NuGet\Nuget.Config)

Конфигурации применяются в обратном порядке, что означает, что в зависимости от указанного выше порядка глобальная конфигурация Nuget.Config будет применена сначала, а затем обнаруженные файлы Nuget.Config из корневой папки в папку проекта..nuget\Nuget.Config Это особенно важно, если элемент используется <clear/> для удаления набора элементов из конфигурации.

Укажите расположение папки "пакеты"

В прошлом NuGet управлял пакетами решения из известной папки "пакеты", найденной под корневой папкой решения. Для команд разработки, имеющих множество различных решений, которые имеют установленные пакеты NuGet, это может привести к установке одного пакета в различных местах в файловой системе.

NuGet 2.1 обеспечивает более детализированный контроль над расположением папки пакетов с помощью repositoryPath элемента в NuGet.Config файле. В предыдущем примере иерархической поддержки Nuget.Config предполагается, что у нас есть все проекты в C:\myteam\ совместно используют одну папку пакетов. Для этого просто добавьте следующую запись c:\myteam\Nuget.Config.

<configuration>
    <config>
    <add key="repositoryPath" value="C:\myteam\teampackages" />
    </config>
    ...
</configuration>

В этом примере общий Nuget.Config файл указывает общую папку пакетов для каждого проекта, созданного под C:\myteam, независимо от глубины. Обратите внимание, что если у вас есть папка пакетов под корнем решения, необходимо удалить ее, прежде чем NuGet будет размещать пакеты в новом расположении.

Поддержка переносимых библиотек

Переносимые библиотеки — это функция, представленная в .NET 4, которая позволяет создавать сборки, которые могут работать без изменений на разных платформах Майкрософт, от версий платформа .NET Framework до Silverlight до Windows Телефон и даже Xbox 360 (хотя в настоящее время NuGet не поддерживает целевую переносимую библиотеку Xbox). Расширяя соглашения о пакетах для версий и профилей платформы, NuGet 2.1 теперь поддерживает переносимые библиотеки, позволяя создавать пакеты с составной платформой и целевыми lib папками профиля.

Например, рассмотрим следующие доступные целевые платформы переносимой библиотеки классов.

После создания библиотеки и выполнения команды nuget.exe pack MyPortableProject.csproj можно просмотреть новую структуру папок пакета переносимой библиотеки, проверив содержимое созданного пакета NuGet.

Как видно, соглашение о имени переносимой библиотеки следует шаблону "portable-{framework 1}+{framework n}", где идентификаторы платформы соответствуют существующим соглашениям о имени и версии платформы. Одно исключение из соглашений об имени и версии найдено в идентификаторе платформы, используемом для Windows Телефон. Этот моникер должен использовать имя платформы WP (wp7, wp71 или wp8). Например, использование silverlight-wp7 приведет к ошибке.

При установке пакета, созданного из этой структуры папок, NuGet теперь может применять свои правила платформы и профиля к нескольким целевым объектам, как указано в имени папки. За правилами сопоставления NuGet является принцип, который "более конкретные" целевые объекты будут иметь приоритет над "менее конкретными". Это означает, что моникеры, предназначенные для конкретной платформы, всегда будут предпочтительнее переносимых, если они совместимы с проектом. Кроме того, если несколько переносимых целевых объектов совместимы с проектом, NuGet предпочитает тот, где поддерживаемый набор платформ является "ближайшим" к проекту, ссылающимся на пакет.

Назначение проектов Windows 8 и Windows Телефон 8

Помимо добавления поддержки для целевых проектов переносимой библиотеки, NuGet 2.1 предоставляет новые моникеры платформы для проектов Магазина Windows 8 и Windows Телефон 8, а также некоторые новые общие моникеры для Магазина Windows и Проектов Windows Телефон, которые будут проще управлять в будущих версиях соответствующих платформ.

Для приложений Магазина Windows 8 идентификаторы выглядят следующим образом:

NuGet 2.0 и более ранних версий	NuGet 2.1
winRT45, . NETCore45	Windows, Windows8, win8, win8

Для проектов Windows Телефон идентификаторы выглядят следующим образом:

ОС Телефон	NuGet 2.0 и более ранних версий	NuGet 2.1
Windows Телефон 7	silverlight3-wp	wp, wp7, Windows Телефон, Windows Телефон 7
Windows Телефон 7.5 (Mango)	silverlight4-wp71	wp71, Windows Телефон 71
Windows Phone 8	(Не поддерживается)	wp8, Windows Телефон 8

Во всех перечисленных выше изменениях старые имена платформ будут полностью поддерживаться NuGet 2.1. Передвигаясь вперед, новые имена должны использоваться, так как они будут более стабильными в будущих версиях соответствующих платформ. Новые имена *не будут поддерживаться в версиях NuGet до 2.1, однако поэтому планируйте соответствующим образом, когда будет выполняться переключение.

Улучшенный поиск в диалоговом окне диспетчер пакетов

За последние несколько итераций изменения были введены в коллекцию NuGet, которая значительно улучшила скорость и релевантность поиска пакетов. Однако эти улучшения были ограничены веб-сайтом nuget.org. NuGet 2.1 обеспечивает улучшенный интерфейс поиска с помощью диалогового окна диспетчера пакетов NuGet. Например, предположим, что вы хотите найти пакет предварительной версии кэширования Windows Azure. Разумный поисковый запрос для этого пакета может быть "Кэш Azure". В предыдущих версиях диалогового окна диспетчера пакетов нужный пакет даже не будет указан на первой странице результатов. Однако в NuGet 2.1 нужный пакет теперь отображается в верхней части результатов поиска.

Принудительное обновление пакета

До NuGet 2.1 NuGet пропустит обновление пакета, если не было большого числа версий. Это ввело трение для определенных сценариев, особенно в случае сценариев сборки или CI, когда команда не хотела увеличивать номер версии пакета с каждой сборкой. Требуемое поведение было принудительное обновление независимо от этого. NuGet 2.1 обращается к этому с флагом "переустановка". Например, предыдущие версии NuGet приводят к следующему при попытке обновить пакет, который не имеет более последней версии пакета:

PM> Update-Package Moq
No updates available for 'Moq' in project 'MySolution.MyConsole'.

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

PM> Update-Package Moq -Reinstall
Successfully removed 'Moq 4.0.10827' from MySolution.MyConsole.
Successfully uninstalled 'Moq 4.0.10827'.
Successfully installed 'Moq 4.0.10827'.
Successfully added 'Moq 4.0.10827' to MySolution.MyConsole.

Другой сценарий, когда флаг переустановки оказывается полезным, является то, что перенацеливание платформы. При изменении целевой платформы проекта (например, с .NET 4 на .NET 4.5) обновление-пакет —переустановка может обновлять ссылки на правильные сборки для всех пакетов NuGet, установленных в проекте.

Изменение источников пакетов в Visual Studio

В предыдущих версиях NuGet обновление источника пакета из диалогового окна параметров Visual Studio требует удаления и повторного добавления источника пакета. NuGet 2.1 улучшает этот рабочий процесс, поддерживая обновление в качестве функции первого класса пользовательского интерфейса конфигурации.

Исправления ошибок

NuGet 2.1 содержит множество исправлений ошибок. Полный список рабочих элементов, исправленных в NuGet 2.0, см. в разделе [NuGet Issue Tracker for this release](http://nuget.codeplex.com/workitem/list/advanced?keyword=&status=Fixed&type=All&priority=All&release=NuGet%202.1&assignedTo=All&component=All&sortField=LastUpdatedDate&sortDirection=Descending&page=0).