Udostępnij za pomocą

Obsługa wielu wersji platformy .NET

Wiele bibliotek jest przeznaczonych dla określonej wersji programu .NET Framework. Na przykład możesz mieć jedną wersję biblioteki specyficzną dla platformy UWP i inną wersję, która korzysta z funkcji w programie .NET Framework 4.6. Aby to uwzględnić, pakiet NuGet obsługuje umieszczanie wielu wersji tej samej biblioteki w jednym pakiecie.

W tym artykule opisano układ pakietu NuGet, niezależnie od tego, jak są tworzone pakiety lub zestawy (czyli układ jest taki sam, niezależnie od tego, czy jest używanych wiele plików csproj w stylu innym niż SDK i niestandardowy plik nuspec , czy jeden wielokierunkowy zestaw SDK w stylu csproj). W przypadku projektu w stylu SDK, docelowe pakiety NuGet wie, jak pakiet powinien być rozmieszczony i automatyzuje umieszczanie bibliotek w odpowiednich folderach lib oraz tworzenie grup zależności dla każdej docelowej platformy strukturalnej (TFM). Aby uzyskać szczegółowe instrukcje, zobacz Obsługa wielu wersji programu .NET Framework w pliku projektu.

Należy ręcznie określić pakiet zgodnie z opisem w tym artykule podczas korzystania z metody katalogów roboczych opartych na konwencji opisanej w temacie Tworzenie pakietu. W przypadku projektu w stylu zestawu SDK zalecana jest metoda zautomatyzowana, ale możesz również ręcznie rozłożyć pakiet zgodnie z opisem w tym artykule.

Struktura folderów wersji frameworka

Podczas budowania pakietu zawierającego tylko jedną wersję biblioteki lub kierowanego na wiele środowisk zawsze należy tworzyć podfoldery pod lib, używając różnych nazw środowisk z zwróceniem uwagi na wielkość liter zgodnie z następującą konwencją:

lib\{framework name}[{version}]

Aby uzyskać pełną listę obsługiwanych nazw, zobacz dokumentację platform docelowych.

Nigdy nie należy mieć wersji biblioteki, która nie jest specyficzna dla struktury i umieszczona bezpośrednio w folderze głównym lib . (Ta funkcja była obsługiwana tylko w programie packages.config). Dzięki temu biblioteka będzie zgodna z dowolną strukturą docelową i pozwoliłaby na jej zainstalowanie w dowolnym miejscu, co prawdopodobnie spowodowało nieoczekiwane błędy środowiska uruchomieniowego. Dodawanie zestawów w folderze głównym (takim jak lib\abc.dll) lub podfolderach (takich jak lib\abc\abc.dll) zostało uznane za przestarzałe i jest ignorowane podczas korzystania z formatu PackagesReference.

Na przykład następująca struktura folderów obsługuje cztery wersje zestawu specyficzne dla platformy:

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

Aby łatwo dołączyć wszystkie te pliki podczas kompilowania pakietu, użyj cyklicznego symbolu wieloznakowego ** w <files> sekcji elementu .nuspec:

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

Foldery specyficzne dla architektury

Jeśli masz zestawy specyficzne dla architektury, czyli oddzielne zestawy przeznaczone dla ARM, x86 i x64, należy umieścić je w folderze o nazwie runtimes, w podfolderach o nazwie {platform}-{architecture}\lib\{framework} lub {platform}-{architecture}\native. Na przykład następująca struktura folderów będzie obsługiwać zarówno natywne, jak i zarządzane biblioteki DLL przeznaczone dla systemu Windows 10 i platformy uap10.0 :

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

Te kompilacje będą dostępne tylko w czasie działania, więc jeśli chcesz podać odpowiednią kompilację czasu kompilacji, umieść kompilację AnyCPU w folderze /ref/{tfm}.

Należy pamiętać, że program NuGet zawsze wybiera te zasoby kompilowania lub uruchamiania aplikacji z jednego folderu, więc jeśli istnieją zgodne zasoby w /ref, to /lib zostanie zignorowane w celu dodania zestawów czasu kompilacji. Podobnie, jeśli istnieją pewne zgodne zasoby w /runtimes, wtedy /lib będzie ignorowane podczas wykonywania.

Zobacz Tworzenie pakietów platformy UWP, aby zapoznać się z przykładem odwoływania się do tych plików w .nuspec manifeście.

Zobacz również artykuł Pakowanie składnika aplikacji ze sklepu Windows za pomocą narzędzia NuGet

Dopasowanie wersji kompilacji i docelowego środowiska w projekcie

Gdy program NuGet instaluje pakiet zawierający wiele wersji zestawu, próbuje dopasować nazwę struktury zestawu do docelowego frameworku projektu.

Jeśli dopasowanie nie zostanie znalezione, pakiet NuGet kopiuje zestaw dla najwyższej wersji, która jest mniejsza lub równa strukturze docelowej projektu, jeśli jest dostępna. Jeśli nie znaleziono zgodnego zestawu, narzędzie NuGet zwraca odpowiedni komunikat o błędzie.

Rozważmy na przykład następującą strukturę folderów w pakiecie:

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

Podczas instalowania tego pakietu w projekcie przeznaczonym dla programu .NET Framework 4.6 program NuGet instaluje zestaw w net45 folderze, ponieważ jest to najwyższa dostępna wersja, która jest mniejsza lub równa 4.6.

Jeśli projekt jest przeznaczony dla programu .NET Framework 4.6.1, z drugiej strony program NuGet instaluje zestaw w folderze net461 .

Jeśli projekt jest przeznaczony dla platformy .NET Framework 4.0 lub starszej, program NuGet zgłasza odpowiedni komunikat o błędzie, aby nie znaleźć zgodnego zestawu.

Grupowanie zestawów według wersji platformy

Narzędzie NuGet kopiuje zestawy tylko z jednego folderu biblioteki w pakiecie. Załóżmy na przykład, że pakiet ma następującą strukturę folderów:

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

Po zainstalowaniu pakietu w projekcie przeznaczonym dla platformy .NET Framework 4.5, MyAssembly.dll (wersja 2.0) jest jedynym zainstalowanym zestawem. MyAssembly.Core.dll (wersja 1.0) nie jest zainstalowana, ponieważ nie znajduje się na liście w folderze net45 . Narzędzie NuGet zachowuje się w ten sposób, ponieważ MyAssembly.Core.dll mogło zostać scalone z wersją 2.0 programu MyAssembly.dll.

Jeśli chcesz, aby MyAssembly.Core.dll był zainstalowany dla .NET Framework 4.5, umieść jego kopię w folderze net45.

Grupowanie zestawów według profilu struktury

Pakiet NuGet obsługuje także celowanie w określony profil frameworka poprzez dodanie kreski i nazwy profilu na końcu folderu.

lib{nazwa platformy}-{profil}

Obsługiwane profile są następujące:

  • client: Profil klienta
  • full: Pełny profil
  • wp:Windows Phone
  • cf: Compact Framework

Deklarowanie zależności (zaawansowane)

Podczas pakowania pliku projektu NuGet próbuje automatycznie wygenerować zależności z projektu. Informacje przedstawione w tej sekcji dotyczące używania pliku nuspec do deklarowania zależności są zwykle niezbędne tylko w przypadku zaawansowanych scenariuszy.

(Wersja 2.0 lub nowsza) Zależności pakietów można zadeklarować w elemencie .nuspec odpowiadającym strukturze docelowej projektu docelowego przy użyciu <group> elementów w elemencie <dependencies> . Aby uzyskać więcej informacji, zobacz element zależności.

Każda grupa ma atrybut o nazwie targetFramework i zawiera zero lub więcej <dependency> elementów. Te zależności są instalowane razem, gdy platforma docelowa jest zgodna z profilem struktury projektu. Aby uzyskać dokładne identyfikatory platform, zobacz Platformy docelowe .

Zalecamy używanie jednej grupy na docelową strukturę Moniker (TFM) dla plików w folderach lib/ i ref/ .

W poniższym przykładzie przedstawiono różne odmiany <group> elementu:

<dependencies>

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

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

</dependencies>

Określenie, który cel NuGet wybrać

Podczas pakowania bibliotek przeznaczonych dla Portable Class Library może być trudno określić, którego docelowego elementu NuGet użyć w nazwach folderów i pliku .nuspec, szczególnie gdy celem jest tylko podzestaw PCL. Następujące zasoby zewnętrzne pomogą Ci w tym:

Pliki zawartości i skrypty programu PowerShell

Ostrzeżenie

Pliki zawartości modyfikowalnej i wykonywanie skryptu są dostępne tylko w packages.config formacie; są przestarzałe ze wszystkimi innymi formatami i nie powinny być używane w przypadku żadnych nowych pakietów.

Za pomocą packages.config pliki zawartości i skrypty PowerShell można grupować według platformy docelowej, korzystając z tej samej konwencji nazywania folderów w obrębie folderów content i tools. Przykład:

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

Jeśli folder platformy pozostanie pusty, pakiet NuGet nie dodaje odwołań do bibliotek, plików zawartości ani nie uruchamia skryptów PowerShell dla tej platformy.

Uwaga / Notatka

Ponieważ init.ps1 jest wykonywany na poziomie rozwiązania i nie jest zależny od projektu, należy go umieścić bezpośrednio w folderze tools . Jest on ignorowany, jeśli znajduje się w folderze frameworka.

  • Last updated on