Správa aktualizací závislostí v projektu .NET

  • 4 min

Dříve nebo později chcete aktualizovat na novou verzi knihovny. Možná je funkce označená jako zastaralá nebo možná existuje nová funkce v novější verzi balíčku, který používáte.

Než se pokusíte knihovnu aktualizovat, měli byste zvážit několik věcí:

  • Typ aktualizace: Jaký typ aktualizace je k dispozici? Je to drobná oprava chyby? Přidává novou funkci, kterou potřebujete? Přeruší váš kód? Typ aktualizace je možné vyčíst díky konvenci, které se říká sémantická správa verzí. Způsob, jakým je číslo verze knihovny vyjádřeno, komunikuje s vývojáři o typu aktualizace, se kterou pracují.
  • Zda je projekt správně nakonfigurovaný: Projekt .NET můžete nakonfigurovat tak, abyste získali pouze požadované typy aktualizací. Aktualizaci provedete jenom v případě, že je k dispozici konkrétní typ aktualizace. Tento přístup doporučujeme, protože riskujete, že narazíte na překvapení.
  • Problémy se zabezpečením: Správa závislostí projektu v průběhu času zahrnuje povědomí o problémech, ke kterým může dojít. Například když se zjistí ohrožení zabezpečení. V ideálním případě se uvolní opravy, které si můžete stáhnout. Nástroj .NET Core vám usnadní audit vašich knihoven – ověří, jestli máte balíčky, které je třeba aktualizovat. Pomůže vám i s příslušnou akcí pro opravu problému.

Sémantická správa verzí

Existuje oborový standard označovaný jako sémantická správa verzí, což je způsob, jakým vyjadřujete typ změny, kterou vy nebo jiný vývojář představujete do knihovny. Sémantické správa verzí funguje tak, že zajišťuje, že balíček má číslo verze a že je číslo verze rozdělené do těchto částí:

  • Hlavní verze: Číslo úplně vlevo. Například je to 1 in 1.0.0. Změna tohoto čísla znamená, že v kódu můžete očekávat "zásadní změny". Je možné, že budete muset část svého kódu přepsat.
  • Podverze: Prostřední číslo. Například je to 2 in 1.2.0. Změna tohoto čísla znamená, že byly přidány funkce. Váš kód by měl i nadále fungovat. Obvykle je bezpečné přijmout aktualizaci.
  • Verze opravy: Číslo úplně vpravo. Například je to 3 in 1.2.3. Změna tohoto čísla znamená, že se použila změna, která opravuje něco v kódu, který by měl fungovat. Přijetí této aktualizace by mělo být bezpečné.

Tato tabulka ukazuje, jak se mění číslo verze u jednotlivých typů verzí:

Typ Co se stane
Hlavní verze 1.0.0 změny v 2.0.0
Podverze 1.1.1 změny v 1.2.0
Verze opravy 1.0.1 změny v 1.0.2

Tento systém používá mnoho společností a vývojářů. Pokud máte v úmyslu publikovat balíčky a odeslat je do registru NuGet, očekává se, že budete postupovat podle sémantické správy verzí. A když balíčky z registru NuGet jen stahujete, můžete předpokládat, že jsou se sémantickou správou verzí v souladu.

Se změnami balíčku se pojí rizika – nějaká chyba by třeba mohla poškodit váš provoz. To by mohlo znamenat, že budete muset přepsat část svého kódu. A přepisování kódu bere čas a stojí peníze.

Jak k aktualizacím přistoupit

Jako vývojář .NET můžete sdělit chování aktualizace, které chcete použít pro .NET. O aktualizacích je dobré přemýšlet z hlediska možných rizik. Tady je několik přístupů:

  • Hlavní verze: Jsem v pořádku s aktualizací na nejnovější hlavní verzi, jakmile bude k dispozici. Souhlasím se skutečností, že možná budu muset změnit kód na konci.
  • Podverze: Jsem v pořádku s přidanou novou funkcí. Nechci, aby se narušil fungující kód.
  • Verze opravy: Jediné aktualizace, se kterými jsem v pořádku, jsou opravy chyb.

Pokud pracujete na novém nebo menším projektu .NET, můžete být při definování strategie pro aktualizace benevolentnější. Například můžete knihovnu vždy aktualizovat na zcela nejnovější verzi. U složitějších projektů je třeba postupovat nuancovaněji, ale to si necháme pro některý z budoucích modulů.

Obecně platí, že čím menší je závislost, kterou aktualizujete, tím méně závislostí má a tím pravděpodobnější, že proces aktualizace je snadný.

Konfigurace souboru projektu pro aktualizaci

Když přidáváte jednu nebo více závislostí, nakonfigurujte soubor projektu tak, abyste při obnovení, sestavení nebo spuštění projektu získali předvídatelné chování. Můžete určit, jaký přístup chcete u balíčku zvolit. NuGet má koncepty rozsahů verzí a plovoucích verzí.

Rozsahy verzí jsou speciální notace, kterou můžete použít k označení konkrétního rozsahu verzí, které chcete vyřešit.

Notace Použité pravidlo Popis
1.0 x >= 1,0 Minimální verze (včetně)
(1.0,) x > 1,0 Minimální verze (vyjma)
[1.0] x == 1.0 Přesná shoda verze
(,1.0] x ≤ 1.0 Maximální verze (včetně)
(,1.0) x < 1,0 Maximální verze (vyjma)
[1.0,2.0] 1.0 ≤ x ≤ 2.0 Přesný rozsah (včetně)
(1.0,2.0) 1,0 < x < 2,0 Přesný rozsah (vyjma)
[1.0,2.0) 1,0 ≤ x < 2,0 Kombinace minimální (včetně) a maximální (vyjma) verze
(1.0) neplatné neplatné

NuGet také podporuje použití zápisu s plovoucí verzí pro hlavní části, podverze, opravu a předběžné přípony čísla. Tato notace je hvězdička (*). Například specifikace verze 6.0.* říká "použít nejnovější verzi 6.0.x". V jiném příkladu 4.* znamená "použít nejnovější verzi 4.x". Použití plovoucí verze snižuje změny v souboru projektu a současně udržuje aktuální nejnovější verzi závislosti.

Poznámka:

Doporučujeme nainstalovat konkrétní verzi místo použití kterékoli notace libovolné verze. Instalace konkrétní verze zajistí, že sestavení budou opakovatelná, pokud explicitně nepožadujete aktualizaci závislosti.

Když používáte plovoucí verzi, NuGet to vyřeší použitím nejvyšší verze balíčku, která odpovídá vzoru verze. V následujícím příkladu 6.0.* získá nejnovější verzi balíčku, který začíná 6.0. Tato verze je 6.0.1.

Diagram znázorňující výběr nejnovější verze při vyžádání plovoucí verze

Tady je několik příkladů, které můžete pro hlavní verzi, podverzi nebo verzi opravy nakonfigurovat:

<!-- Accepts any version 6.1 and later. -->
<PackageReference Include="ExamplePackage" Version="6.1" />

<!-- Accepts any 6.x.y version. -->
<PackageReference Include="ExamplePackage" Version="6.*" />
<PackageReference Include="ExamplePackage" Version="[6,7)" />

<!-- Accepts any later version, but not including 4.1.3. Could be
     used to guarantee a dependency with a specific bug fix. -->
<PackageReference Include="ExamplePackage" Version="(4.1.3,)" />

<!-- Accepts any version earlier than 5.x, which might be used to prevent pulling in a later
     version of a dependency that changed its interface. However, we don't recommend this form because determining the earliest version can be difficult. -->
<PackageReference Include="ExamplePackage" Version="(,5.0)" />

<!-- Accepts any 1.x or 2.x version, but not 0.x or 3.x and later. -->
<PackageReference Include="ExamplePackage" Version="[1,3)" />

<!-- Accepts 1.3.2 up to 1.4.x, but not 1.5 and later. -->
<PackageReference Include="ExamplePackage" Version="[1.3.2,1.5)" />

Hledání a aktualizace zastaralých balíčků

Příkaz dotnet list package --outdated vytvoří výpis zastaralých balíčků. Díky tomu se případně dozvíte, že jsou k dispozici jejich novější verze. Tady je typický výstup z tohoto příkazu:

Top-level Package      Requested   Resolved   Latest
> Humanizer            2.7.*       2.7.9      2.8.26

Sloupce ve výstupu mají tyto významy:

  • Requested: Zadaný rozsah verze nebo verze.
  • Resolved: Skutečná verze stažená pro projekt, která odpovídá zadané verzi.
  • Latest: Nejnovější verze dostupná pro aktualizaci z NuGetu.

Doporučeným pracovním postupem je spustit následující příkazy v tomto pořadí:

  1. Spusťte dotnet list package --outdated. Ten vypíše všechny zastaralé balíčky. Informace zobrazí ve sloupcích Requested, Resolved a Latest.
  2. Spusťte dotnet add package <package name>. Pokud spustíte tento příkaz, pokusí se aktualizovat na nejnovější verzi. Volitelně ji můžete určit předáním argumentu --version=<version number/range>.