Övergripande migreringsstrategi

Inledning

Windows App SDK innehå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 använda din befintliga kompetensuppsättning och källkod på ett bra sätt 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.

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:

• För frågor och feedback om Windows App SDK, eller bara för att starta en diskussion, använder du knappen This product. Du kan också starta en diskussion på fliken Discussions för lagringsplatsen WindowsAppSDK GitHub. 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?

Med Windows App SDK kan du förbättra din app med nya plattformsfunktioner, samt med det moderna Windows UI 3 Library (WinUI), som är utvecklat och utformat för att glädja användarna.

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

Värdeförslaget 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å plattformar för skrivbordsappar.
• 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

Installera Windows App SDK VSIX

Ladda ned den senaste Windows App SDK versionen från Windows App SDK nedladdningar och kör för att installera den.

Skapa ett nytt projekt

I Visual Studio Skapa ditt första WinUI-project. Använd till exempel projektmallen WinUI Blank App (Packaged). Du hittar den project mallen i Skapa en ny dialogruta project genom att välja språk: C# eller C++; plattform: Windows App SDK; project typ: WinUI eller Desktop.

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

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 vyn DetailPage och 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). Visst kan vi inte förvänta oss att få en ren build förrän vi hade spårat upp alla beroenden och i huvudsak portat hela projektet i ett jättehopp.

Om vi å andra sidan skulle börja med den del av project 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 filerna själva med hjälp av Utforskaren och sedan läggas de 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ålet project 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 projektet.
• 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 kopiera sedan innehållet av dessa källkodsfiler från källprojektet till målprojektet. För en C++/WinRT-project 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 kod-bakom-filer för XAML-vyer i form av 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 vy-modeller) med namnet MyPage, måste du lägga till MyPage.xaml.cpp direkt efter #include "MyPage.g.cpp". 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 ditt målprojekt ett annat namn än det ursprungliga projektet. Om du gör det kommer det att påverka standardnamnområdet i källprojektet. När du kopierar källkoden från källan project till målet project kan du behöva ändra namnområdesnamn som nämns i källkoden.

Att ändra project namn (och därmed standardnamn för namnområdet) är något som vi gör, till exempel i fallstudien A Windows App SDK migrering av UWP PhotoLab-exempelappen (C#). I den fallstudien kopierar vi inte filinnehåll från källan till målprojektet, utan hela filer med hjälp av Utforskaren. Källnamnet project/namnområde är PhotoLab och målnamnet project/namnområde ä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ällan project har beroenden på. Installera sedan samma NuGet-paket i målprojektet.

I exemplet på fallstudien A Windows App SDK-migrering av UWP PhotoLab-exempelappen (C#) innehåller källprojektet referenser till Microsoft.Graphics.Win2D NuGet-paketet. Så i denna fallstudie lägger vi till referenser till samma NuGet-paket till målprojektet.

Relaterade ämnen

• Windows App SDK och windowsversioner som stöds
• Windows Runtime (WinRT) API:er
• WinUI
• PhotoLab fallstudie
• fotoredigerarens fallstudie
• Windows Runtime API:er stöds inte i skrivbordsappar