Поделиться через

Поддержка нескольких версий .NET

Многие библиотеки предназначены для конкретной версии .NET Framework. Например, у вас может быть одна версия библиотеки, относящуюся к UWP, и другая версия, которая использует преимущества функций в .NET Framework 4.6. Для этого NuGet поддерживает размещение нескольких версий одной библиотеки в одном пакете.

В этой статье описывается макет пакета NuGet, независимо от того, как создаются пакеты или сборки (т. е. макет одинаков, будь то с использованием нескольких файлов .csproj, не в стиле SDK, и пользовательского файла .nuspec, или одного многоцелевого файла в стиле SDK .csproj). Для проекта в стиле SDK цели пакетов NuGet знают, как должен быть организован пакет, и автоматизируют размещение сборок в правильных папках lib и создание групп зависимостей для каждой целевой платформы (TFM). Подробные инструкции см. в разделе "Поддержка нескольких версий .NET Framework" в файле проекта.

Необходимо вручную разместить пакет, как описано в этой статье при использовании метода рабочего каталога на основе соглашения, описанного в разделе Создание пакета. Для проекта в стиле SDK рекомендуется использовать автоматизированный метод, но вы также можете вручную структурировать пакет, как описано в этой статье.

Структура папок версии Framework

При создании пакета, содержащего только одну версию библиотеки или нацеленного на несколько фреймворков, всегда создавайте вложенные папки под lib с использованием различных регистрозависимых названий фреймворков по следующему соглашению:

lib\{framework name}[{version}]

Полный список поддерживаемых имен см. в справочнике по целевым платформам.

У вас никогда не должна быть версия библиотеки, которая не связана с платформой и помещается непосредственно в корневую lib папку. (Эта возможность поддерживается только с packages.config). Это обеспечит совместимость библиотеки с любым целевым фреймворком и позволит установить её в любом месте, что, вероятно, приведет к непредвиденным ошибкам среды выполнения. Добавление сборок в корневую папку (такие как lib\abc.dll) или вложенные папки (такие как lib\abc\abc.dll) устарело и игнорируется при использовании формата PackagesReference.

Например, следующая структура папок поддерживает четыре версии сборки, которые зависят от фреймворка.

\lib
    \net46
        \MyAssembly.dll
    \net461
        \MyAssembly.dll
    \uap
        \MyAssembly.dll
    \netcore
        \MyAssembly.dll

Чтобы легко включить все эти файлы при создании пакета, используйте рекурсивный подстановочный знак в разделе .

<files>
    <file src="lib\**" target="lib/{framework name}[{version}]" />
</files>

Папки, относящиеся к архитектуре

Если у вас есть архитектурно-специфические сборки, то есть отдельные сборки, предназначенные для ARM, x86 и x64, их необходимо поместить в папку с именем runtimes в подкаталогах с именами {platform}-{architecture}\lib\{framework} и {platform}-{architecture}\native. Например, следующая структура папок будет размещать как собственные, так и управляемые библиотеки DLL, предназначенные для Windows 10 и платформы uap10.0 :

\runtimes
    \win10-arm
        \native
        \lib\uap10.0
    \win10-x86
        \native
        \lib\uap10.0
    \win10-x64
        \native
        \lib\uap10.0

Эти сборки будут доступны только во время выполнения, поэтому, если вы хотите предоставить соответствующую сборку времени компиляции, для этого разместите сборку AnyCPU в папке /ref/{tfm}.

Обратите внимание, что NuGet всегда выбирает эти ресурсы компиляции или среды выполнения из одной папки, поэтому, если из нее есть некоторые совместимые ресурсы /ref , /lib будут игнорироваться для добавления сборок во время компиляции. Аналогично, если имеются совместимые ресурсы /runtimes, тогда /lib также будут игнорироваться во время выполнения.

Пример ссылки на эти файлы в манифесте см. в разделе .nuspec".

Кроме того, см. раздел "Упаковка компонента приложения магазина Windows" с помощью NuGet

Сопоставление версий сборок и целевой платформы в проекте

Когда NuGet устанавливает пакет с несколькими версиями сборок, он пытается сопоставить имя платформы сборки с целевой платформой проекта.

Если совпадение не найдено, NuGet копирует сборку для самой старшей версии, которая меньше или равна целевой платформе проекта, если она доступна. Если совместимая сборка не найдена, NuGet возвращает соответствующее сообщение об ошибке.

Например, рассмотрим следующую структуру папок в пакете:

\lib
    \net45
        \MyAssembly.dll
    \net461
        \MyAssembly.dll

При установке этого пакета в проекте, который предназначен для .NET Framework 4.6, NuGet устанавливает сборку в net45 папке, так как это самая высокая доступная версия, которая меньше или равна 4.6.

Если проект предназначен для .NET Framework 4.6.1, с другой стороны, NuGet устанавливает сборку в папке net461 .

Если проект предназначен для .NET Framework 4.0 и более ранних версий, NuGet выдает соответствующее сообщение об ошибке, чтобы не найти совместимую сборку.

Группирование сборок по версии платформы

NuGet копирует сборки только из одной папки библиотеки в пакете. Например, предположим, что пакет имеет следующую структуру папок:

\lib
    \net40
        \MyAssembly.dll (v1.0)
        \MyAssembly.Core.dll (v1.0)
    \net45
        \MyAssembly.dll (v2.0)

Если пакет установлен в проекте, предназначенный для .NET Framework 4.5, MyAssembly.dll (версия 2.0) является единственной сборкой. MyAssembly.Core.dll (версия 1.0) не установлен, так как он не указан в папке net45 . NuGet ведет себя таким образом, так как MyAssembly.Core.dll возможно объединён в версию 2.0 MyAssembly.dll.

Если вы хотите MyAssembly.Core.dll установить для .NET Framework 4.5, поместите копию в папку net45 .

Группирование сборок по профилю платформы

NuGet также поддерживает назначение определенного профиля платформы путем добавления дефиса и имени профиля в конец папки.

lib{имя платформы}-{profile}

Поддерживаемые профили приведены следующим образом:

  • client: профиль клиента
  • full: полный профиль
  • wp:Windows Phone
  • cf: Compact Framework

Объявление зависимостей (дополнительно)

При упаковке файла проекта NuGet пытается автоматически создать зависимости из проекта. Сведения в этом разделе об использовании nuspec-файла для объявления зависимостей обычно необходимы только для расширенных сценариев.

(Версия 2.0+) Можно объявить зависимости пакетов в nuspec , соответствующем целевой платформе целевого проекта, с помощью <group> элементов в элементе <dependencies> . Дополнительные сведения см. в разделе "Элементы зависимостей".

Каждая группа имеет атрибут с именем targetFramework и содержит ноль или несколько <dependency> элементов. Эти зависимости устанавливаются вместе, если целевая платформа совместима с профилем платформы проекта. Сведения о целевых платформах см. в разделе "Целевые платформы" для точных идентификаторов платформ.

Рекомендуется использовать одну группу на Moniker (TFM) для целевой платформы для файлов в папках lib/ и ref/.

В следующем примере показаны различные варианты <group> элемента:

<dependencies>

    <group targetFramework="net472">
        <dependency id="jQuery" version="1.10.2" />
        <dependency id="WebActivatorEx" version="2.2.0" />
    </group>

    <group targetFramework="net20">
    </group>

</dependencies>

Определение используемого целевого объекта NuGet

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

Файлы содержимого и скрипты PowerShell

Предупреждение

Изменяемые файлы содержимого и выполнение скриптов доступны только в packages.config формате; они считаются устаревшими во всех других форматах и их не следует использовать для новых пакетов.

С помощью packages.config файлы содержимого и скрипты PowerShell могут быть сгруппированы по целевому фреймворку с использованием той же структуры папок внутри папок content и tools. Рассмотрим пример.

\content
    \net46
        \MyContent.txt
    \net461
        \MyContent461.txt
    \uap
        \MyUWPContent.html
    \netcore
\tools
    init.ps1
    \net46
        install.ps1
        uninstall.ps1
    \uap
        install.ps1
        uninstall.ps1

Если папка платформы пуста, NuGet не добавляет ссылки на сборки или файлы содержимого или запускает скрипты PowerShell для этой платформы.

Замечание

Так как init.ps1 выполняется на уровне решения и не зависит от проекта, он должен быть помещен непосредственно в папку tools . Он игнорируется, если он помещается в каталог фреймворка.

  • Last updated on