Podpora více verzí .NET

Mnoho knihoven cílí na konkrétní verzi rozhraní .NET Framework. Můžete mít například jednu verzi knihovny, která je specifická pro UPW, a jinou verzi, která využívá funkce v rozhraní .NET Framework 4.6. Aby se to přizpůsobilo, NuGet podporuje vložení více verzí stejné knihovny do jednoho balíčku.

Tento článek popisuje rozložení balíčku NuGet bez ohledu na to, jak jsou sestaveny balíčky nebo sestavení (to znamená, že rozložení je stejné bez ohledu na to, jestli používáte více souborů .csproj ve stylu sady SDK a vlastní soubor .nuspec nebo jeden soubor .csproj s více cílenými sadami SDK). V případě projektu ve stylu sady SDK cíl balíčku NuGet ví, jak musí být balíček rozložený, a automatizuje umístění sestavení do správných složek knihovny lib a vytváření skupin závislostí pro každou cílovou architekturu (TFM). Podrobné pokyny naleznete v tématu Podpora více verzí rozhraní .NET Framework v souboru projektu.

Balíček musíte ručně rozložit, jak je popsáno v tomto článku při použití metody pracovního adresáře založené na konvenci popsané v části Vytvoření balíčku. Pro projekt ve stylu sady SDK se doporučuje automatizovaná metoda, ale můžete také zvolit ruční rozložení balíčku, jak je popsáno v tomto článku.

Struktura složek verzí architektury

Při vytváření balíčku, který obsahuje pouze jednu verzi knihovny nebo cíl více architektur, vždy vytváříte podsložky lib s použitím různých názvů architektur rozlišujících malá a velká písmena s následující konvencí:

lib\{framework name}[{version}]

Úplný seznam podporovaných názvů najdete v referenčních informacích k cílovým architekturám.

Nikdy byste neměli mít verzi knihovny, která není specifická pro architekturu a umístěná přímo do kořenové lib složky. (Tato funkce byla podporována pouze s packages.config). Díky tomu by knihovna byla kompatibilní s jakoukoli cílovou architekturou a umožňovala ji instalovat kdekoli, což by pravděpodobně vedlo k neočekávaným chybám za běhu. Přidávání sestavení do kořenové složky (například lib\abc.dll) nebo podsložek (například lib\abc\abc.dll) bylo zastaralé a při použití formátu PackagesReference se ignoruje.

Například následující struktura složek podporuje čtyři verze sestavení, které jsou specifické pro architekturu:

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

Pokud chcete při vytváření balíčku snadno zahrnout všechny tyto soubory, použijte rekurzivní ** zástupný znak v <files> části vašeho .nuspecsouboru:

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

Složky specifické pro architekturu

Pokud máte sestavení specifická pro architekturu, tedy samostatná sestavení, která cílí na ARM, x86 a x64, musíte je umístit do složky s názvem runtimes{platform}-{architecture}\lib\{framework} podsložky nebo {platform}-{architecture}\native. Například následující struktura složek by vyhovovala nativním i spravovaným knihovenm DLL, které cílí na Windows 10 a architekturu uap10.0 :

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

Tato sestavení budou k dispozici pouze za běhu, takže pokud chcete poskytnout odpovídající sestavení času kompilace a pak mít AnyCPU sestavení ve /ref/{tfm} složce.

Mějte na paměti, že NuGet tyto prostředky kompilace nebo modulu runtime vždy vybere z jedné složky, takže pokud jsou některé kompatibilní prostředky z /ref této složky, /lib budou ignorovány pro přidání sestavení v době kompilace. Podobně platí, že pokud jsou z /runtimes nich některé kompatibilní prostředky, budou se pro modul runtime ignorovat také /lib .

Příklad odkazu na tyto soubory v manifestu .nuspec najdete v tématu Vytvoření balíčků UPW.

Viz Balení komponenty aplikace pro Windows Store pomocí NuGetu

Odpovídající verze sestavení a cílová architektura v projektu

Když NuGet nainstaluje balíček s více verzemi sestavení, pokusí se shodovat s názvem architektury sestavení s cílovou architekturou projektu.

Pokud se shoda nenajde, NuGet zkopíruje sestavení pro nejvyšší verzi, která je menší nebo rovna cílové rozhraní projektu, pokud je k dispozici. Pokud se nenajde žádné kompatibilní sestavení, nuGet vrátí příslušnou chybovou zprávu.

Představte si například následující strukturu složek v balíčku:

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

Při instalaci tohoto balíčku do projektu, který cílí na rozhraní .NET Framework 4.6, NuGet nainstaluje sestavení do net45 složky, protože je to nejvyšší dostupná verze, která je menší nebo rovna 4.6.

Pokud projekt cílí na rozhraní .NET Framework 4.6.1, na druhou stranu NuGet nainstaluje sestavení do net461 složky.

Pokud projekt cílí na rozhraní .NET Framework 4.0 a starší, vyvolá NuGet odpovídající chybovou zprávu, která nenajde kompatibilní sestavení.

Seskupování sestavení podle verze architektury

NuGet kopíruje sestavení pouze z jedné složky knihovny v balíčku. Předpokládejme například, že balíček má následující strukturu složek:

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

Pokud je balíček nainstalován v projektu, který cílí na rozhraní .NET Framework 4.5, MyAssembly.dll (v2.0) je jediné nainstalované sestavení. MyAssembly.Core.dll (v1.0) není nainstalován, protože není uvedený ve net45 složce. NuGet se chová tímto způsobem, protože MyAssembly.Core.dll mohl být sloučen do verze 2.0 z MyAssembly.dll.

Pokud chcete MyAssembly.Core.dll nainstalovat rozhraní .NET Framework 4.5, umístěte kopii do net45 složky.

Seskupení sestavení podle profilu architektury

NuGet také podporuje cílení na konkrétní profil architektury připojením pomlčky a názvu profilu na konec složky.

lib{framework name}-{profile}

Podporované profily jsou následující:

• client: Profil klienta
• full: Úplný profil
• wp: Windows Telefon
• cf: Kompaktní architektura

Deklarování závislostí (Upřesnit)

Při balení souboru projektu se NuGet pokusí automaticky vygenerovat závislosti z projektu. Informace v této části o použití souboru .nuspec k deklaraci závislostí jsou obvykle nezbytné pouze pro pokročilé scénáře.

(Verze 2.0+) Závislosti balíčků můžete deklarovat v souboru .nuspec odpovídající cílovému rozhraní cílového projektu pomocí <group> prvků v elementu <dependencies> . Další informace naleznete v tématu závislosti elementu.

Každá skupina má pojmenovaný targetFramework atribut a obsahuje nula nebo více <dependency> prvků. Tyto závislosti se nainstalují společně, když je cílová architektura kompatibilní s profilem architektury projektu. Přesné identifikátory rozhraní najdete v cílových architekturách.

Pro soubory v knihovněa složkách ref/ doporučujeme použít jednu skupinu pro jedno moniker cílového rozhraní (TFM).

Následující příklad ukazuje různé varianty elementu <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>

Určení cíle NuGet, který se má použít

Při balení knihoven určených pro přenosnou knihovnu tříd může být obtížné určit, který cíl NuGet byste měli použít v názvech a .nuspec souborech složek, zejména pokud cílíte jenom na podmnožinu PCL. S tím vám pomůžou následující externí zdroje:

• Profily rozhraní v .NET (stephencleary.com)
• Profily knihovny přenosných tříd (plnkr.co): Výčet profilů PCL a jejich ekvivalentních cílů NuGet
• Nástroj pro profily knihovny přenosných tříd (github.com): nástroj příkazového řádku pro určení profilů PCL dostupných v systému

Soubory obsahu a skripty PowerShellu

Upozorňující

Proměnlivé soubory obsahu a spouštění skriptů jsou dostupné pouze ve packages.config formátu. Jsou zastaralé se všemi ostatními formáty a neměly by se používat pro žádné nové balíčky.

Soubory packages.configobsahu a skripty PowerShellu lze seskupit podle cílové architektury pomocí stejné konvence složek uvnitř content a tools složek. Příklad:

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

Pokud je složka architektury prázdná, NuGet nepřidá odkazy na sestavení ani soubory obsahu ani nespustí skripty PowerShellu pro danou architekturu.

Poznámka:

Vzhledem k tomu init.ps1 , že se provádí na úrovni řešení a není závislý na projektu, musí být umístěn přímo pod tools složku. Pokud je umístěná ve složce architektury, bude ignorována.