Poznámka:
Přístup k této stránce vyžaduje autorizaci. Můžete se zkusit přihlásit nebo změnit adresáře.
Přístup k této stránce vyžaduje autorizaci. Můžete zkusit změnit adresáře.
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 balíky nebo sestavení vytvářeny (to znamená, že rozložení je stejné bez ohledu na to, jestli používáte více souborů .csproj ne ve stylu SDK a vlastní soubor .nuspec nebo jediný soubor ve stylu SDK .csproj pro více cílení). 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 verze rámce
Při vytváření balíčku, který obsahuje pouze jednu verzi knihovny nebo při cílení na více rámců, vždy vytváříte podsložky pod lib s použitím různých názvů rámců citlivých na velikost písmen 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) je 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 oddělená sestavení, která cílí na ARM, x86 a x64, musíte je umístit do složky pojmenované runtimes v podsložkách pojmenovaných {platform}-{architecture}\lib\{framework} 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 také odpovídající sestavení pro čas kompilace, umístěte sestavení do složky /ref/{tfm}.
Mějte na paměti, že NuGet vždy vybere tyto prostředky pro kompilaci nebo běhové prostředí z jedné složky, takže pokud existují nějaké kompatibilní prostředky z /ref, pak prostředky z /lib budou ignorovány pro přidání do sestavení v době kompilace. Podobně platí, že pokud jsou některá kompatibilní aktiva z /runtimes, bude /lib během vykonávání programu také ignorováno.
Příklad odkazu na tyto soubory v manifestu najdete v tématu .nuspec.
Viz také Balení komponenty aplikace 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 porovnat název frameworku sestavení s cílovým frameworkem projektu.
Pokud se nenajde shoda, NuGet zkopíruje sestavení pro nejvyšší verzi, která je menší nebo rovna cílovému frameworku 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 Phone -
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.
Doporučujeme použít jednu skupinu pro každý moniker cílového rozhraní (TFM) pro soubory ve složkách lib/ a ref/.
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
Výstraha
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 obsahu packages.config a skripty PowerShellu lze seskupit podle cílového rozhraní pomocí stejné konvence složek uvnitř složek content a tools. Napří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:
Protože init.ps1 je prováděno na úrovni řešení a není závislé na projektu, musí být umístěno přímo pod složku tools. Pokud je umístěná ve složce architektury, bude ignorována.