Vytvoření plánu přenosu

Než se pustíte přímo do kódu, projděte si doporučené kroky před migrací. Tento článek poskytuje přehled o typech problémů, se kterými se můžete setkat, a pomůže vám rozhodnout se o přístupu, který dává největší smysl.

Důležitý

API Port byl zrušen na úkor binární analýzy pomocí nástroje .NET Upgrade Assistant. Back-endová služba portu rozhraní API byla vypnuta, takže pokud chcete nástroj používat, musíte ho používat offline. Další informace najdete v README portu .NET API.

Portujte svůj kód.

Než budete pokračovat, ujistěte se, že dodržujete požadavky na portování kódu . Připravte se, abyste se rozhodli, který je pro vás nejvhodnější, a začněte portovat kód.

Důležitý

Pomocník pro upgrade platformy .NET je oficiálně zastaralý. Místo toho použijte agenta pro chatování a modernizaci GitHub Copilotu, který je zahrnutý v sadách Visual Studio 2026 a Visual Studio 2022 verze 17.14.16 nebo novější. Tento agent analyzuje vaše projekty a závislosti, vytvoří podrobný plán migrace s cílenými doporučeními a automatizovanými opravami kódu a potvrdí každou změnu, abyste ji mohli ověřit nebo vrátit zpět. Automatizuje běžné úlohy přenosu – aktualizace souborů projektu, nahrazení zastaralých rozhraní API a řešení problémů se sestavením– abyste mohli rychleji modernizovat s menším ručním úsilím.

Zabývat se primárně kompilátorem

Tento přístup funguje dobře u malých projektů nebo projektů, které nepoužívají mnoho rozhraní API rozhraní .NET Framework. Přístup je jednoduchý:

  1. Volitelně můžete na projektu spustit ApiPort . Pokud spustíte ApiPort, získejte přehled z přehledu o problémech, které je třeba řešit.
  2. Zkopírujte veškerý kód do nového projektu .NET.
  3. Při odkazování se na sestavu přenositelnosti (pokud je vygenerována), odstraňujte chyby kompilátoru, dokud se projekt plně nezkompiluje.

I když je nestrukturovaný, tento přístup zaměřený na kód často řeší problémy rychle. Projekt, který obsahuje pouze datové modely, může být ideálním kandidátem pro tento přístup.

Zůstaňte v rozhraní .NET Framework, dokud se nevyřeší problémy s přenositelností.

Tento přístup může být nejlepší, pokud dáváte přednost kódu, který se kompiluje během celého procesu. Přístup je následující:

  1. Spusťte apiPort v projektu.
  2. Vyřešte problémy pomocí různých rozhraní API, která jsou přenosná.
  3. Poznamenejte si všechny oblasti, ve kterých nemůžete použít přímou alternativu.
  4. Opakujte předchozí kroky pro všechny projekty, které portujete, dokud si nejste jistí, že každý z nich je připravený ke zkopírování do nového projektu .NET.
  5. Zkopírujte kód do nového projektu .NET.
  6. Vyřešte všechny problémy, ve kterých jste si poznamenali, že neexistuje přímá alternativa.

Tento opatrný přístup je strukturovanější než pouhé řešení chyb kompilátoru, ale stále je poměrně zaměřený na kód a má tu výhodu, že kód vždy projde kompilací. Způsob řešení určitých problémů, které se nedají vyřešit jenom pomocí jiného rozhraní API, se výrazně liší. Možná zjistíte, že potřebujete vytvořit komplexnější plán pro určité projekty, na které se vztahuje další přístup.

Vytvoření komplexního plánu útoku

Tento přístup může být nejvhodnější pro větší a složitější projekty, kdy pro podporu .NET může být nutné kód restrukturalizace nebo úplné přepsání určitých oblastí kódu. Přístup je následující:

  1. Spusťte apiPort v projektu.

  2. Pochopte, kde se používá každý nepřenosný typ a jak to ovlivňuje celkovou přenositelnost.

    • Porozumějte povaze těchto typů. Jsou malé v čísle, ale často se používají? Jsou početné, ale používají se zřídka? Je jejich použití soustředěné, nebo se šíří v celém kódu?
    • Je snadné izolovat kód, který není přenosný, abyste s ním mohli efektivněji pracovat?
    • Potřebujete refaktorovat kód?
    • U typů, které nejsou přenosné, existují alternativní rozhraní API, která provádějí stejnou úlohu? Pokud například používáte třídu WebClient, použijte místo toho třídu HttpClient.
    • Jsou k dispozici různá přenosná rozhraní API pro provedení úlohy, i když se nejedná o výměnu? Pokud například používáte k analýze XML, ale nevyžadujete zjišťování schématu XML, můžete použít XmlSchemaSystem.Xml.Linq rozhraní API a implementovat analýzu sami místo toho, abyste se museli spoléhat na rozhraní API.

  3. Pokud máte sestavení, která se obtížně portují, stojí za to je prozatím ponechat v rozhraní .NET Framework? Je potřeba vzít v úvahu některé skutečnosti:

    • V knihovně můžete mít některé funkce, které nejsou kompatibilní s rozhraním .NET, protože je příliš silně závislé na funkcích specifických pro .NET Framework nebo Windows. Stojí za to nechat tuto funkci za sebou a vydat dočasnou verzi knihovny .NET s menším počtem funkcí, dokud nebudou prostředky dostupné pro přenos funkcí?
    • Pomohlo by refaktoring?

  4. Je vhodné napsat vlastní implementaci nedostupného rozhraní .NET Framework API?

    Můžete zvážit kopírování, úpravy a použití kódu z referenčního zdroje rozhraní .NET Framework. Referenční zdrojový kód je licencovaný v rámci licence MIT, takže máte významnou svobodu používat zdroj jako základ pro vlastní kód. Nezapomeňte správně přiřazovat Microsoft ve vašem kódu.

  5. Tento proces opakujte podle potřeby pro různé projekty.

Fáze analýzy může nějakou dobu trvat v závislosti na velikosti základu kódu. V této fázi trávíte čas, abyste důkladně porozuměli rozsahu potřebných změn a vyvinuli plán, obvykle vám ušetří čas na konci, zejména pokud máte složitý základ kódu.

Váš plán může zahrnovat provádění významných změn základu kódu, zatímco stále cílí na rozhraní .NET Framework 4.7.2. Jedná se o strukturovanější verzi předchozího přístupu. Způsob provádění plánu závisí na základu kódu.

Smíšený přístup

Je pravděpodobné, že výše uvedené přístupy budete kombinovat na základě jednotlivých projektů. Udělejte, co pro vás a pro základ kódu dává největší smysl.

Přenos testů

Nejlepším způsobem, jak zajistit, aby vše fungovalo při přenosu kódu, je otestovat kód při jeho přenosu do .NET. K tomu budete muset použít testovací architekturu, která sestaví a spustí testy pro .NET. V současné době máte tři možnosti:

V konečném důsledku úsilí o přenos závisí hodně na tom, jak je váš kód rozhraní .NET Framework strukturovaný. Dobrým způsobem, jak kód přenést, je začít základem knihovny, což jsou základní komponenty kódu. Může to být datové modely nebo jiné základní třídy a metody, které všechno ostatní používá přímo nebo nepřímo.

  1. Portujte testovací projekt, který testuje vrstvu vaší knihovny, kterou právě portujete.
  2. Zkopírujte základ knihovny do nového projektu .NET a vyberte verzi .NET Standard, kterou chcete podporovat.
  3. Proveďte všechny změny potřebné ke kompilaci kódu. Většina z toho může vyžadovat přidání závislostí balíčků NuGet do souboru csproj .
  4. Spusťte testy a proveďte potřebné úpravy.
  5. Vyberte další vrstvu kódu, která se má přenést, a opakujte předchozí kroky.

Pokud začnete se základnou knihovny a podle potřeby se posunete ze základny a otestujete jednotlivé vrstvy, portování je systematický proces, kdy jsou problémy izolované na jednu vrstvu kódu najednou.

Další kroky

  • Last updated on