Dela via

Övergripande migreringsstrategi

  • Artikel

Inledning

Windows App SDK tillhandahåller en bred uppsättning Windows-API:er – med implementeringar som är frikopplade från operativsystemet och som släpps till utvecklare via NuGet--paket. Som utvecklare med ett UWP-program (Universal Windows Platform) kan du dra stor nytta av din befintliga kompetensuppsättning och källkod genom att flytta din app till Windows App SDK.

Med Windows App SDK kan du införliva de senaste funktionerna för körning, språk och plattform i din app. Eftersom varje program är olika, och det är även dina krav och inställningar, finns det många olika sätt att hantera processen med att migrera appens källkod. Men metoden på hög nivå och de kodändringar som behövs för olika funktionsområden är liknande. I det här avsnittet går vi därför igenom strategier för hur du kan migrera din app, samt mer information (och begränsningar) om vissa funktionsområden. Se även Vad som stöds vid portning från UWP till WinUI 3.

De flesta Windows Runtime (WinRT) API:er kan användas av Windows App SDK-appar. Men det finns vissa som inte stöds i skrivbordsappar eller har begränsningar.

  • API:er som har beroenden av gränssnittsfunktioner som endast har utformats för användning i UWP-appar.
  • API:er som kräver paketidentitet. Dessa API:er stöds endast i skrivbordsappar som paketeras med HJÄLP av MSIX.

För dessa API:er visar vi vilka alternativ du kan använda. De flesta av dessa alternativ är tillgängliga i WinUI-eller via WinRT COM-gränssnitt som är tillgängliga i Windows App SDK.

Vi ser till exempel vissa användargränssnittsscenarier där du behöver spåra huvudfönsterobjektet och använder olika HWND--baserade API:er och interoperationsmönster, till exempel IInitializeWithWindow::Initiera.

Anmärkning

Se även Windows Runtime-API:er som inte stöds i skrivbordsappar. Windows App SDK-appar är en typ av skrivbordsapp. Andra typer av skrivbordsappar är .NET-skrivbordsappar och C/C++ Win32-skrivbordsappar. Målgruppen för det ämnet är utvecklare som vill migrera till allt i unionen av dessa olika typer av skrivbordsappar, inklusive (men inte begränsat till) Windows App SDK-appar.

Vi vill gärna höra din feedback om den här migreringsguiden och om din egen migreringsupplevelse. Använd avsnittet Feedback precis vid foten av den här sidan så här:

  • Om du vill ha frågor och feedback om Windows App SDK eller bara starta en diskussion använder du knappen Den här produkten. Du kan också starta en diskussion på fliken Diskussioner för WindowsAppSDK GitHub-lagringsplatsen. Med hjälp av dessa kanaler kan du också berätta för oss vilket problem du försöker lösa, hur du har försökt lösa det hittills och vad som skulle vara den perfekta lösningen för din app.
  • Om du vill ha feedback om saknad eller felaktig information i den här migreringsguiden använder du knappen Den här sidan.

Varför migrera till Windows App SDK?

Windows App SDK ger dig en möjlighet att förbättra din app med nya plattformsfunktioner, samt med det moderna Windows UI 3-bibliotek (WinUI 3), som är utvecklat och utformat för att glädja dina användare.

Dessutom är Windows App SDK bakåtkompatibel; den stöder appar ned till Windows 10 version 1809 (10.0; Build 17763) – även kallat Windows 10 Oktober 2018 Update.

Värdeerbjudandet med att flytta Windows App SDK är mångfacetterat. Här följer några överväganden:

  • Den senaste användargränssnittsplattformen (UI) och kontroller som WinUI 3 och WebView2.
  • En enda API-yta på skrivbordsappplattformar.
  • Mer frekvent utgivningstakt som lanseras separat från Windows.
  • En konsekvent upplevelse i Windows-versioner.
  • .NET-kompatibilitet.
  • Bakåtkompatibel ned till Windows 10 version 1809.
  • Förbättrad exekveringsmiljö. Se MSIX-container.

Mer information finns i Windows App SDK.

Översikt över migreringsprocessen

Anmärkning

Du kan tänka på UWP-versionen av appen som du vill migrera som källan lösningen/projektet (det är källan av migreringsprocessen). Windows App SDK-versionen är mållösning (det är mål av migreringsprocessen).

Installera Windows App SDK VSIX

Ladda ned installationsprogrammet för Windows App SDK Visual Studio-tillägget (VSIX) från Stable-versionskanalen för Windows App SDK-och kör för att installera det.

Skapa ett nytt projekt

I Visual Studio Skapa ditt första WinUI 3-projekt. Använd till exempel Tom app, paketerad (WinUI 3 i skrivbordsmiljö) projektmall. Du hittar projektmallen i dialogrutan Skapa ett nytt projekt genom att välja språk: C# eller C++; plattform: Windows App SDK; projekttyp: WinUI eller Desktop.

Du ser två projekt i Solution Explorer– det ena är kvalificerat som (Desktop)och det andra som (paket).

Migrera kod med minst beroenden först

För att illustrera den här rekommendationen ska vi ta PhotoLab-fallstudien som exempel. För PhotoLab-exempelappen kan en uppenbar metod vara att börja med att migrera MainPage-– eftersom det är en så viktig och framträdande del av appen. Men om vi skulle göra det skulle vi snart inse att MainPage- har ett beroende av DetailPage-vyn; och sedan att DetailPage har ett beroende av modellen Photo. Om vi skulle följa den vägen kanske vi ständigt avbryter oss själva (växlar över till att arbeta med varje nyupptäckt beroende). Självklart skulle vi inte förvänta oss att få en ren build förrän vi hade fixat alla beroenden och i princip portat hela projektet i ett gigantiskt språng.

Om vi å andra sidan skulle börja med den del av projektet som inte är beroende av något annat, och arbeta utåt därifrån (från minst till mest beroende bit), skulle vi kunna fokusera på varje stycke en i taget. Och vi skulle också kunna uppnå en felfri version efter att ha migrerat varje del, och på så sätt bekräfta att migreringsprocessen håller sig på rätt spår.

Så när du migrerar dina egna appar rekommenderar vi att du migrerar kod med minst beroenden först.

Kopiera filer eller kopiera filinnehåll?

När du migrerar kopierar du naturligtvis över resursfilerna (och inte innehållet i resursfilen ). Men hur är det med källkodsfiler? Som ett exempel tar vi återigen MainPage--klassen från PhotoLab-fallstudien och fallstudien Photo Editor.

C#. I C#-versionen (PhotoLab) består MainPage av källkodsfilerna MainPage.xaml och MainPage.xaml.cs.

C++/WinRT. I C++/WinRT-versionen (fotoredigeraren) består MainPage- av källkodsfilerna MainPage.xaml, MainPage.idl, MainPage.hoch MainPage.cpp.

Så du kan välja mellan dessa två alternativ:

  • (Rekommenderas) du kan kopiera över själva filerna (med hjälp av Utforskaren) och sedan lägga till kopiorna i målprojektet. Undantag till den här rekommendationen är filer som App.xaml och App.xaml.cs, eftersom filerna redan finns i målprojektet, och de innehåller källkod som är specifik för Windows App SDK. För dessa måste du slå samman källkoden som redan finns där med källkoden från källprojektet.
  • Du kan också använda Visual Studio för att skapa nya Page-filer (till exempel MainPage.xaml och MainPage.xaml.cs) i målprojektet, och sedan kopiera innehållet i dessa källkodsfiler från källprojektet till målprojektet. För ett C++/WinRT-projekt innebär det här alternativet många fler steg.

Se även avsnittet MainPage och MainWindow.

Skillnader mellan mapp- och filnamn (C++/WinRT)

I ett C++/WinRT UWP-projekt namnges code-behind-filer för XAML-vyer i formen MainPage.h och MainPage.cpp. Men i en C++/WinRT Windows App SDK måste du byta namn på dem till MainPage.xaml.h och MainPage.xaml.cpp.

I ett C++/WinRT UWP-projekt, när du migrerar en hypotetisk XAML-vy (i betydelsen modeller, vyer och viewmodels) med namnet MyPagei MyPage.xaml.cpp måste du lägga till #include "MyPage.g.cpp" direkt efter #include "DetailPage.xaml.h". Och för en hypotetisk modell med namnet MyModeli MyModel.cpp lägga till #include "MyModel.g.cpp" omedelbart efter #include "MyModel.h". Ett exempel finns i Migrera DetailPage-källkod.

Om du ändrar namnet på ditt migrerade projekt

När du migrerar kan du välja att ge målprojektet ett annat namn än källprojektets. Om du gör det påverkar det standardnamnområdet i källprojektet. När du kopierar källkoden från källprojektet till målprojektet kan du behöva ändra namnområdesnamn som nämns i källkoden.

Att ändra projektnamn (och därmed standardnamn för namnområde) är något som vi gör, till exempel i fallstudien En Windows App SDK-migrering av UWP PhotoLab-exempelappen (C#). I den fallstudien kopierar vi hela filer med Utforskaren i stället för att kopiera över fil innehåll från källan till målprojektet. Namnet på källprojektet/namnområdet är PhotoLaboch målprojektets/namnområdets namn är PhotoLabWinUI3. Därför måste vi söka efter PhotoLab- i innehållet i alla källkodsfiler som vi kopierade över och ändra det till PhotoLabWinUI3

I just den fallstudien gjorde vi ändringarna i App.xaml, App.xaml.cs, MainPage.xaml, MainPage.xaml.cs, DetailPage.xaml, DetailPage.xaml.cs, ImageFileInfo.csoch LoadedImageBrush.cs.

Installera samma NuGet-paket som installerades i källprojektet

En uppgift under migreringsprocessen är att identifiera alla NuGet-paket som källprojektet har beroenden för. Installera sedan samma NuGet-paket i målprojektet.

I fallstudien En Windows App SDK-migrering av UWP PhotoLab-exempelappen (C#)innehåller källprojektet till exempel referenser till Microsoft.Graphics.Win2D NuGet-paketet. Så i den fallstudien lägger vi till en referens till samma NuGet-paket i målprojektet.