Správa aktualizací závislostí v projektu .NET
Dříve nebo později budete chtít provést aktualizaci 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? Mohla by narušit 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í. Aktualizace proběhne jen v případě, že je k dispozici konkrétní typ. 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ě budou vydány 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 v 1.0.0. Změna v tomto čísle znamená, že je možné v kódu 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 v 1.2.0. Změna v tomto čísle znamená, že byly přidány funkce. Váš kód by měl i nadále fungovat. Obecně platí, že přijetí této aktualizace by mělo být bezpečné.
- Verze opravy: Číslo úplně vpravo. Například je to 3 v 1.2.3. Změna v tomto čísle znamená, že v kódu proběhla změna s cílem opravit něco, co mělo fungovat už dříve. 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í:
| Type | Co se stane |
|---|---|
| Hlavní verze | 1.0.0 na 2.0.0 |
| Podverze | 1.1.1 na 1.2.0 |
| Verze opravy | 1.0.1 na 1.0.2 |
Tuto konvenci dodržuje mnoho společností a vývojářů. Pokud máte v úmyslu publikovat balíčky a odeslat je do registru NuGet, měli byste postupovat podle sémantické správy verzí; Očekává se to. 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ě dalších závislostí zahrnuje a tím je pravděpodobnější, že proces aktualizace proběhne hladce.
Konfigurace souboru projektu pro aktualizaci
Když přidáváte jednu nebo více závislostí, zamyslete se nad konfigurací souboru projektu, abyste získali předvídatelné chování při obnovení, kompilaci a spuštění projektu. Můžete určit, jaký přístup chcete u balíčku zvolit. NuGet zná koncept rozsahů verzí a plovoucích verzí.
Nejprve si promluvme o rozsahu verzí. Toto je speciální notace, která se používá k určení rozsahů konkrétních 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 notaci plovoucí verze pro hlavní verzi, podverzi, verzi opravy a přípony čísla předběžné verze. 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.
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í:
- Spusťte
dotnet list package --outdated. Ten vypíše všechny zastaralé balíčky. Informace zobrazí ve sloupcíchRequested,ResolvedaLatest. - Spusťte
dotnet add package <package name>. Při spuštění se tento příkaz pokusí provést aktualizaci na nejnovější verzi. Volitelně ji můžete určit předáním argumentu--version=<version number/range>.