Přehled upgradu aplikací model Windows Forms

Tento článek vám pomůže pochopit, co je součástí upgradu aplikace model Windows Forms z .NET Framework na .NET. model Windows Forms podporuje .NET a přijímá aktivní investice, včetně novějších ovládacích prvků, vylepšení vysokého DPI a aktualizací přístupnosti. Pokud udržujete existující model Windows Forms aplikaci a chcete tato vylepšení využít nebo přejít na podporovanou .NET verzi, je tento článek určený pro vás.

Článek se zabývá důvody upgradu, dostupnými cestami upgradu a přípravnou prací, která upgrade hladce provede. Vysvětluje také, které technologie .NET Framework nemají v .NET žádný ekvivalent, jak vyplnit mezery rozhraní API pomocí sady Windows Compatibility Pack a jak mohou zásadní změny ovlivnit vaši aplikaci.

Příklad upgradu najdete v tématu Upgrade aplikace model Windows Forms na .NET s využitím modernizace GitHub Copilot.

Proč upgradovat

.NET Framework je modul runtime jen pro Windows, který už nepřijímá aktualizace funkcí. I když i nadále dostává bezpečnostní opravy pro podporované verze, nevyužívá práci na výkonu, vylepšení jazyka ani aktivní investice, ze kterých .NET těží. Pokud udržujete Windows aplikaci v .NET Frameworku, upgrade na .NET vám poskytne přístup k rychlejší a schopnější platformě, která je aktivně vyvinuta v otevřeném prostředí.

Udržování aktuálních verzí .NET je také důležité. Každá verze .NET má definované okno podpory a aplikace běžící na verzi, která není podporována, přestanou přijímat opravy zabezpečení a opravy. Upgradujte před ukončením podpory, abyste zůstali chráněni.

.NET nabízí smysluplná vylepšení výkonu při spouštění za běhu, propustnosti a využití paměti. Desktopové aplikace na .NET také využívají průběžné investice do funkcí:

  • Novější ovládací prvky, vylepšení přístupnosti a vylepšení s vysokým rozlišením DPI
  • Lepší integrace s Windows Některé funkce, jako je tmavý režim na Windows 11, jsou dostupné jenom na .NET.
  • Novější funkce jazyka C# a Visual Basic a vylepšené nástroje
  • Bohatý ekosystém balíčků NuGet, které cílí na .NET.

.NET každý rok vydává novou hlavní verzi, která se střídá mezi dlouhodobými verzemi podpory (LTS) a standardní podporou (STS):

  • Verze LTS se podporují po dobu tří let a jsou obvykle nejlepší volbou pro produkční aplikace, které dávají přednost stabilitě.
  • Verze služby STS se podporují po dobu 24 měsíců a jsou užitečné, když chcete začít používat nové funkce dříve.

Naplánujte harmonogram upgradů s ohledem na tato data, aby vaše aplikace vždy běžela na podporované verzi. Aktuální podporované verze a data ukončení podpory najdete v .NET verzích, opravách a podpoře.

Cesty aktualizace

Většina upgradů spadá do jedné ze dvou kategorií. Určete, která cesta se týká vaší aplikace, a pak k dokončení práce použijte pokyny a nástroje v tomto článku.

  • Od .NET Framework po .NET: Nejvýznamnější změna.

    Formát souboru projektu, některá rozhraní API a určité technologie se liší. Než začnete, projděte si požadavky, vyhodnoťte závislosti a naplánujte mezery v rozhraní API.

    Jakmile aplikaci sestavíte a spustíte v .NET, můžete případně přejít na novější postupy, jako je konfigurace appsettings.json, vkládání závislostí nebo cloudové služby. Zavedení těchto vzorů je oddělené od modernizace na platformu .NET a není nutné k dokončení přechodu. Nápady a pokyny najdete v tématu Modernizace po upgradu na .NET z .NET Frameworku.

  • Ze starší verze .NET na novější verzi: Upgrade s menším rozsahem.

    Hlavními úlohami jsou aktualizace monikeru cílové architektury, kontrola zásadních změn pro verze, které překračujete, a aktualizace závislostí NuGet.

Upgrade z architektury .NET na .NET

Upgrade z .NET Framework na .NET je nejvýznamnější cestou upgradu a hlavním cílem této části.

Important

I když je .NET multiplatformní technologie, desktopové aplikace pro Windows v .NET stále zůstávají pouze pro Windows.

Jednou změnou je formát souboru projektu. .NET používá formát projektu ve stylu sady SDK, který je stručnější než starší formát. Soubor projektu můžete převést na styl sady SDK, i když stále cílí na rozhraní .NET Framework, což snižuje rozsah změn během skutečného portu a poskytuje lepší směrný plán pro práci.

V .NET nejsou k dispozici všechna rozhraní API .NET Framework. Některá rozhraní API navenek existují, ale za běhu vyvolají PlatformNotSupportedException. Sada Windows Compatibility Pack (Microsoft.Windows.Compatibilitybalíček NuGet) vyplňuje mnoho z těchto mezer tím, že poskytuje přístup k rozhraním API specifických pro Windows, jako je registr Windows, Windows protokol událostí a další. Podrobnosti najdete v tématu Použití sady Windows Compatibility Pack k přenosu kódu pro .NET.

Některé technologie .NET Framework nemají v .NET žádný ekvivalent a vyžadují alternativní přístupy, jako jsou domény aplikací, zabezpečení přístupu kódu (CAS) a Windows Workflow Foundation. Další informace naleznete v části Nedostupné technologie .NET Framework.

Auditujte závislosti třetích stran. Ovládací prvky a knihovny, které cílí jenom na .NET Framework, nemusí na .NET fungovat. Upřednostněte balíčky NuGet, které cílí přímo .NET Standard 2.0 nebo .NET. V případě balíčků, které nebyly portovány, vyhledejte alternativy komunity nebo zkontrolujte, jestli Windows Compatibility Pack pokrývá potřebná rozhraní API.

Upgrade mezi verzemi .NET

Přechod z jedné .NET verze na jinou – například z .NET 9 na .NET 10 – je obvykle menší úsilí než modernizace z .NET Frameworku. Hlavním úkolem je aktualizovat vlastnost <TargetFramework> v projektovém souboru na nový moniker cílového frameworku. Například změna net9.0-windows na net10.0-windows.

Než cíl aktualizujete, projděte si dokumentaci k zásadním změnám pro každou verzi, kterou překračujete. Zásadní změny mohou spočívat v chování, ovlivňovat binární kompatibilitu nebo kompatibilitu zdrojového kódu nebo měnit chování v návrhové době. I malé rozdíly mezi vedlejšími verzemi mohou přinést změny, které mohou ovlivnit vaši aplikaci. Projděte si zásadní změny v .NET a vyfiltrujte rozsah verzí, ve kterém upgradujete.

Po aktualizaci cílové architektury aktualizujte závislosti NuGet. Balíčky, které cílí na starší verze .NET, můžou mít novější verze, které využívají aktuální modul runtime. Vyhledejte aktualizace a upřednostněte balíčky, které cílí na verzi, na kterou přecházíte. Některé balíčky můžou mít také zastaralá rozhraní API nebo změněné chování v novějších verzích, proto si přečtěte poznámky k verzi při aktualizaci.

modernizace aplikací GitHub Copilot

Agent modernizace GitHub Copilot je doporučený nástroj pro modernizaci aplikací model Windows Forms a WPF (Windows Presentation Foundation). Jedná se o ucelené prostředí založené na umělé inteligenci integrované do GitHub Copilot, které zpracovává celý proces upgradu.

Agent se řídí třífázovým pracovním postupem:

  • Hodnocení. Copilot prozkoumá strukturu projektu, závislosti a vzory kódu. Identifikuje zásadní změny, problémy s kompatibilitou rozhraní API, zastaralé vzory a celkový rozsah upgradu. Před pokračováním pak prezentuje rozhodnutí o strategii, jako je pořadí upgradu a zpracování kompatibility.

  • Plánování. Copilot převede posouzení a potvrzené volby na podrobný plán upgradu, dokumentuje strategie upgradu, přístupy refaktoringu, cesty závislostí a zmírnění rizik.

  • Spuštění. Copilot rozdělí plán na postupné úlohy s ověřovacími kritérii, použije opravy kódu a potvrdí změny přírůstkově. Pokud narazí na problém, který nedokáže automaticky vyřešit, požádá vás o pomoc a poučí se z této opravy.

Veškerý stav aktualizace je uložen v .github/upgrades/ ve vašem úložišti, takže ji můžete pozastavit a znovu obnovit i v dalších relacích nebo přepínat mezi vývojovými prostředími, aniž byste přišli o postup.

Agent podporuje tyto cesty upgradu:

  • .NET Framework (libovolná verze) pro .NET 8 nebo novější
  • .NET Core 1.x–3.x na .NET 8 nebo novější
  • .NET 5–7 na .NET 8 nebo novější verzi
  • Migrace na služby Azure

Je k dispozici v Visual Studio 2026, Visual Studio 2022 17.14.16 nebo novější, Visual Studio Code a GitHub CLI. Pokud chcete zahájit upgrade ve Visual Studiu, klikněte pravým tlačítkem myši na své řešení nebo projekt v Průzkumník řešeníu a vyberte Modernize, nebo otevřete okno GitHub Copilot Chat a zadejte @Modernize. V Visual Studio Code otevřete panel Copilot Chat GitHubu a zadejte @modernize-dotnet.

Podrobnosti o nastavení a využití najdete v tématu Co je GitHub Copilot modernizace?.

Nedostupné technologie rozhraní .NET Framework

Několik technologií .NET Framework nemá v .NET žádné ekvivalenty a před spuštěním aplikace v novém modulu runtime vyžadují alternativní přístupy. Zjistěte co nejdříve, zda vaše aplikace závisí na některé z těchto technologií, protože představují nejnáročnější kategorii migračních prací. Úplné informace najdete v článku Technologie rozhraní .NET Framework, které nejsou v .NET k dispozici.

  • Domény aplikací

    AppDomain není podporováno. Použijte AssemblyLoadContext pro dynamické načítání sestavení a pro izolaci používejte samostatné procesy nebo kontejnery. Některé prvky rozhraní API AppDomain jsou přítomné, ale za běhu vyvolají výjimku PlatformNotSupportedException.

  • Vzdálené komunikace

    Technologie .NET Remoting není podporována. Použijte System.IO.Pipes nebo MemoryMappedFile pro místní IPC, gRPC a ASP.NET Core pro komunikaci mezi počítači. Volání BeginInvoke() a EndInvoke() na objektech delegátů také vyvolají PlatformNotSupportedException.

  • Zabezpečení přístupu kódu (CAS)

    CAS není podporováno a již není bezpečnostní hranicí. Místo toho používejte hranice zabezpečení na úrovni operačního systému, jako jsou virtualizace, kontejnery nebo uživatelské účty.

  • Transparentnost zabezpečení

    Transparentnost zabezpečení, která odděluje kód v izolovaném prostoru (sandbox) od kódu kritického pro zabezpečení, se už nepodporuje jako hranice zabezpečení. Podobně jako CAS se tato funkce spoléhala na vynucování za běhu, které .NET neposkytuje. Místo toho používejte mechanismy izolace na úrovni operačního systému.

  • Windows Workflow Foundation (WF)

    WF není v .NET podporováno. Pokud vaše aplikace hostuje nebo používá pracovní postupy, zvažte CoreWF, open source port modulu runtime Windows Workflow Foundation, který cílí na .NET.

  • System.EnterpriseServices (COM+)

    System.EnterpriseServices není podporováno. Aplikace, které prostřednictvím System.EnterpriseServices používají služby COM+, jako je sdružování objektů, transakce nebo zabezpečení na základě rolí, je třeba přepracovat tak, aby využívaly alternativní řešení. U distribuovaných transakcí zvažte System.Transactions. V případě scénářů hostování služeb zvažte ASP.NET Core nebo služby pracovních procesů.

Mějte na paměti, že některá API v těchto oblastech jsou v .NET k dispozici, ale za běhu vyvolají výjimku PlatformNotSupportedException namísto selhání při kompilaci. Otestujte svou aplikaci na platformě .NET už v rané fázi migrace, abyste tyto problémy odhalili dříve, než investujete do kompletního přenesení.

Než začnete s upgradem z rozhraní .NET Framework

Před zahájením přenosu aplikace do .NET dokončete sadu přípravných kroků, zatímco projekt stále cílí na .NET Framework. Když nejprve provedete tuto přípravu, snížíte rozsah změn během samotné aktualizace a získáte přehlednější, ověřený výchozí stav, ze kterého můžete vycházet. Kompletní referenční informace najdete v tématu Požadavky na přenos kódu z rozhraní .NET Framework.

  • Upgradujte nástroje.

    Ujistěte se, že používáte verzi Visual Studio, která podporuje verzi .NET, na kterou chcete cílit. Novější verze sady SDK zahrnují vylepšenou podporu migrace, lepší analyzátory a aktualizované šablony projektů. Relace mezi .NET SDK, MSBuild a Visual Studio verzemi najdete v tématu Relace správy verzí mezi .NET SDK, MSBuild a Visual Studio.

  • Jako cíl použijte .NET Framework 4.7.2 nebo novější.

    Před přenesením projekt znovu nastavte na .NET Framework 4.7.2 nebo vyšší. Tato verze poskytuje nejširší plochu kompatibility rozhraní API s .NET Standard 2.0, což snižuje počet mezer rozhraní API, se kterými se setkáte během upgradu.

    V Visual Studio klikněte pravým tlačítkem myši na projekt, vyberte Vlastnosti a potom změňte rozevírací seznam Target Framework na .NET Framework 4.7.2. Před pokračováním překompilujte a opravte všechny problémy.

  • Převeďte na formát PackageReference.

    Pokud váš projekt používá soubor packages.config ke správě referencí NuGet, migrujte na formát PackageReference. PackageReference je moderní přístup a integruje se přímo do formátu projektu ve stylu sady SDK, který použijete v dalším kroku.

    V aplikaci Visual Studio klikněte pravým tlačítkem na packages.config v Průzkumníku řešení a vyberte možnost Migrovat soubor packages.config na PackageReference. Než budete pokračovat, zkontrolujte výstup migrace a vyřešte všechna upozornění.

  • Převeďte na formát projektu ve stylu sady SDK.

    Přepněte soubor projektu do formátu stylu sady SDK. Projekty ve stylu SDK jsou kompaktnější, podporují cílení na více cílových rozhraní a jsou vyžadovány pro .NET. Tento převod je možné provést i přesto, že cílí na .NET Framework, takže se jedná o bezpečný přípravný krok. Mnoho nástrojů pro převod to zpracovává automaticky nebo můžete ručně převést nahrazením obsahu souboru projektu ekvivalentem stylu sady SDK a opětovným přidáním nezbytných vlastností.

  • Aktualizace závislostí NuGet

    Aktualizujte všechny balíčky NuGet na jejich nejnovější verze a upřednostněte balíčky, které cílí na .NET Standard 2.0, a ne balíčky, které cílí pouze na .NET Framework. Tím se sníží riziko blokování závislostí při změně cílové architektury. Projděte si poznámky k verzi balíčku, kde najdete všechny zásadní změny zavedené v novějších verzích.

Před upgradem na .NET všechny předchozí návrhy zajistí, aby vaše projekty byly v dobrém stavu.

Balíček kompatibility pro Windows

Jedním z nejběžnějších problémů při přenosu z rozhraní .NET Framework chybí rozhraní API. .NET Standard záměrně vylučuje technologie, které nemohou fungovat napříč všemi platformami, jako je například registr Windows, WMI a Reflection.Emit, takže tato rozhraní API nejsou ve výchozím nastavení k dispozici. Balíček Microsoft.Windows.Compatibility NuGet vyplní danou mezeru. Poskytuje přibližně 20 000 rozhraní API v následujících technologických oblastech:

  • Registr systému Windows
  • Protokol událostí systému Windows
  • Windows Management Instrumentation (WMI)
  • Čítače výkonu Windows
  • Adresářové služby
  • Seznamy řízení přístupu systému Windows (ACL)
  • Služby Windows
  • Kryptografie systému Windows
  • WCF (Windows Communication Foundation)
  • Porty, ODBC, CodeDom a další

Balíček se nachází nad .NET Standard 2.0 a je zvlášť užitečný při postupné modernizaci. Umožní vám nejprve sestavovat a spouštět aplikace na .NET a pak se zabývat hlubším refaktoringem později, aniž byste museli předem přepisovat využití rozhraní API specifické pro Windows.

Pokud ho Microsoft.Windows.Compatibility chcete přidat do projektu, nainstalujte balíček NuGet:

dotnet add package Microsoft.Windows.Compatibility

Úplné podrobnosti najdete v tématu Použití sady Windows Compatibility Pack k přenosu kódu do .NET.

Zásadní změny

Zásadní změny jsou očekávanou součástí jakéhokoli upgradu bez ohledu na to, jestli portujete z .NET Frameworku nebo přecházíte mezi verzemi .NET. Když je před zahájením zkontrolujete, předejdete překvapením v pozdější fázi migrace. Úplný odkaz najdete v tématu Zásadní změny při přenosu kódu.

Zásadní změny spadají do několika kategorií a ne všechny z nich způsobují chyby při kompilaci:

  • Změny chování ovlivňují fungování rozhraní API za běhu. Signatura zůstává stejná, ale mění se výstup, vyhazované výjimky nebo interní chování. Tyto se odhalují nejhůře, protože nezpůsobují chyby sestavení.
  • Binární změny kompatibility ovlivňují, zda existující kompilovaná sestavení nadále fungují bez rekompilace. Odebráním nebo změnou povrchu veřejného rozhraní API dojde k přerušení binární kompatibility.
  • Změny kompatibility zdroje vyžadují, abyste před úspěšné kompilací zkompilovali zdrojový kód proti novější verzi.
  • Změny kompatibility v době návrhu ovlivňují, jak se projekty otevírají a chovají ve Visual Studiu nebo v jiných návrhových prostředích.

Při přenosu z .NET Frameworku překračujete velkou mezeru ve verzi, takže seznam potenciálních změn je delší. Při upgradu mezi verzemi .NET , například z .NET 6 na .NET 9, je rozsah užší, ale každá verze mezi tím může zavést změny, které ovlivňují vaši aplikaci. Zkontrolujte zásadní změny pro každou verzi, kterou přeskočíte, a ne jenom cílovou verzi.

Zásadní změny specifické pro model Windows Forms jsou popsané v zásadních změnách migrace z rozhraní .NET Framework na .NET. Vyfiltrujte zásadní změny v rozsahu verzí, ve kterém upgradujete, a zkontrolujte položky, které platí pro rozhraní API, která vaše aplikace používá.

Úlohy po upgradu

Jakmile se vaše aplikace sestaví a spustí na .NET, dokončete několik úloh čištění a odeberte artefakty z upgradu.

Zkontrolujte balíčky NuGet.

Proces aktualizace mohl aktualizovat balíčky na novější verze. Některé z těchto novějších verzí odeberou závislosti, které vyžadují starší verze. Po upgradu zkontrolujte každý aktualizovaný balíček a odeberte všechny přechodné závislosti, které už nejsou potřeba. Projděte si poznámky k verzi, kde najdete aktualizované balíčky, abyste zachytili změny chování, které nezpůsobují chyby sestavení.

Vyčistěte staré artefakty NuGet.

Pokud váš projekt použil packages.config soubor ke správě odkazů NuGet, po migraci do PackageReference formátu už ho nepotřebujete. Odstraňte ho z projektu. Můžete také odstranit místní packages složku v projektu nebo adresáři řešení – NuGet teď ukládá balíčky do globální složky mezipaměti ve .nuget\packages vašem profilu uživatele.

Aktualizujte System.Configuration odkazy.

Většina aplikací .NET Framework odkazuje System.Configuration přímo. Po upgradu může váš projekt i nadále tento odkaz obsahovat. Knihovna System.Configuration čte ze souboru app.config pro konfiguraci za běhu. V .NET ho nahraďte balíčkem System.Configuration.ConfigurationManager NuGet, který poskytuje stejnou plochu rozhraní API bez odkazu na přímé sestavení architektury.

Modernizace po upgradu

Po spuštění aplikace na .NET můžete využít moderní vzory, které nejsou dostupné v .NET Frameworku. Tyto změny nejsou nutné k dokončení upgradu, ale zlepšují udržovatelnost a využívají aktivní investice do .NET. Širší sadu nápadů najdete v tématu Modernizace po upgradu na .NET z .NET Frameworku.

Migrace z App.config na appsettings.json.

.NET Framework používá App.config pro nastavení za běhu, jako jsou připojovací řetězce a konfigurace protokolování. Aplikace .NET místo toho obvykle používají appsettings.json, který poskytuje balíček Microsoft.Extensions.ConfigurationNuGet. Mnoho knihoven, včetně poskytovatelů protokolování, zrušilo podporuApp.config ve prospěch appsettings.json. Migrace aplikace odpovídá ekosystému a zjednodušuje konfiguraci při přidávání nových závislostí.

App.config soubory nadále fungují v .NET prostřednictvím System.Configuration.ConfigurationManager balíčku NuGet, takže můžete migrovat přírůstkově. Pokyny najdete v tématu Konfigurace v .NET.

Nahraďte ovládací prvek WebBrowser pomocí WebView2 (WPF (Windows Presentation Foundation)).

Ovládací WebBrowser prvek je založený na Internet Explorer, který se už nepodporuje. WPF (Windows Presentation Foundation) pro .NET může místo toho používat ovládací prvek WebView2, který je založený na Microsoft Edgi. WebView2 poskytuje moderní, aktivně udržovaný ovládací prvek prohlížeče s vylepšenou podporou výkonu, zabezpečení a webových standardů.

Přidejte do Microsoft.Web.WebView2 projektu balíček NuGet. V závislosti na tom, jakou verzi Windows uživatel spustí, může být nutné nainstalovat modul runtime WebView2 samostatně. Další informace naleznete v tématu Úvod do Microsoft Edge WebView2.

Související obsah

  • Last updated on