Udostępnij za pośrednictwem

Ogólna strategia migracji

  • Artykuł

Wprowadzenie

Zestaw SDK aplikacji systemu Windows udostępnia szeroki zestaw interfejsów API systemu Windows — z implementacjami, które są oddzielone od systemu operacyjnego, i udostępniane deweloperom za pośrednictwem pakietów NuGet. Jako deweloper z aplikacją platformy uniwersalnej systemu Windows (UWP) możesz doskonale wykorzystać istniejący zestaw umiejętności i kod źródłowy, przenosząc aplikację do zestawu SDK aplikacji systemu Windows.

Zestaw SDK aplikacji systemu Windows umożliwia uwzględnienie najnowszych funkcji środowiska uruchomieniowego, języka i platformy w aplikacji. Ponieważ każda aplikacja jest inna, a więc wymagania i preferencje, istnieje wiele różnych sposobów podejścia do procesu migracji kodu źródłowego aplikacji. Jednak podejście wysokiego poziomu i zmiany kodu potrzebne dla różnych obszarów funkcji są podobne. W tym temacie omówimy strategie migracji aplikacji, a także więcej informacji (i ograniczeń) dotyczących niektórych obszarów funkcji. Zobacz również Co jest obsługiwane podczas przenoszenia z platformy UWP do winUI 3.

Większość interfejsów API środowiska uruchomieniowego systemu Windows (WinRT) może być używana przez aplikacje zestawu SDK aplikacji systemu Windows. Istnieją jednak pewne, które nie są obsługiwane w aplikacjach klasycznych lub mają ograniczenia.

  • API, które mają zależności od funkcji UI, zaprojektowanych do użytku tylko w aplikacjach UWP.
  • Interfejsy API wymagające tożsamości pakietu. Te interfejsy programowania aplikacji (API) są obsługiwane tylko w aplikacjach na komputery stacjonarne, które są pakowane z użyciem MSIX.

W przypadku tych interfejsów API pokażemy, jakie alternatywy mają być używane. Większość z tych alternatyw jest dostępna w WinUIlub za pośrednictwem interfejsów COM WinRT, które są dostępne w zestawie SDK aplikacji systemu Windows.

Na przykład zobaczymy pewne scenariusze interfejsu użytkownika, w których będziesz musiał śledzić główny obiekt okna i używać różnych HWNDopartych na API oraz wzorcach współdziałania, takich jak IInitializeWithWindow::Initialize.

Uwaga

Zobacz również API środowiska uruchomieniowego Windows, które nie są obsługiwane w aplikacjach na komputery stacjonarne. Aplikacje Windows App SDK są jednym rodzajem aplikacji desktopowych. Inne rodzaje aplikacji klasycznych to aplikacje klasyczne platformy .NET i aplikacje klasyczne Win32 C/C++. Odbiorcami tego tematu są deweloperzy, którzy chcą przeprowadzić migrację do czegokolwiek w unii tych różnych rodzajów aplikacji desktopowych, w tym (ale nie tylko) aplikacji Windows App SDK.

Chcielibyśmy usłyszeć Twoją opinię na temat tego przewodnika po migracji oraz Twoje doświadczenia związane z migracją. Użyj sekcji Feedback bezpośrednio u stóp tej strony w następujący sposób:

  • W przypadku pytań i opinii dotyczących zestawu SDK aplikacji systemu Windows lub po prostu, aby rozpocząć dyskusję, użyj przycisku Ten produkt. Możesz również rozpocząć dyskusję na karcie Dyskusje w repozytorium GitHub WindowsAppSDK. Korzystając z tych kanałów, możesz również powiedzieć nam, jaki problem próbujesz rozwiązać, jak próbowano go rozwiązać do tej pory i jakie byłoby idealne rozwiązanie dla twojej aplikacji.
  • Aby uzyskać opinię na temat brakujących lub nieprawidłowych informacji w tym przewodniku migracji, użyj przycisku Ta strona.

Dlaczego warto przeprowadzić migrację do zestawu SDK aplikacji systemu Windows?

Zestaw SDK aplikacji systemu Windows oferuje możliwość ulepszenia aplikacji za pomocą nowych funkcji platformy, a także nowoczesnej biblioteki interfejsu użytkownika systemu Windows 3 (WinUI 3), która została opracowana i zaprojektowana, aby cieszyć użytkowników.

Ponadto zestaw SDK aplikacji systemu Windows ma wsteczną kompatybilność; obsługuje aplikacje w systemie Windows 10 od wersji 1809 (10.0; Kompilacja 17763), określana także jako aktualizacja z października 2018 r. dla systemu Windows 10.

Propozycja wartości wynikająca z przeniesienia zestawu SDK aplikacji Windows ma wiele aspektów. Oto kilka zagadnień:

  • Najnowsza platforma i kontrolki interfejsu użytkownika, takie jak WinUI 3 i WebView2.
  • Pojedynczy obszar interfejsu API na platformach aplikacji biurkowych.
  • Częstsze cykle wydań, które są wydawane oddzielnie od systemu Windows.
  • Spójne środowisko w różnych wersjach systemu Windows.
  • Zgodność platformy .NET.
  • Kompatybilne wstecz aż do Windows 10, wersja 1809.
  • Ulepszone środowisko uruchomieniowe. Zobacz kontener MSIX.

Aby uzyskać więcej informacji, zobacz Zestaw SDK aplikacji systemu Windows.

Omówienie procesu migracji

Uwaga

Możesz traktować wersję aplikacji UWP, którą chcesz migrować, jako rozwiązanie/projekt źródłowe (jest to źródło procesu migracji). Wersja zestawu SDK aplikacji systemu Windows jest rozwiązaniem docelowym (jest to docelowy procesu migracji).

Instalowanie zestawu WINDOWS App SDK VSIX

Pobierz instalator rozszerzenia programu Visual Studio (VSIX) zestawu SDK aplikacji Windows z kanału stabilnej wersji dla zestawu SDK aplikacji Windowsi uruchom go, aby zainstalować.

Tworzenie nowego projektu

W programie Visual Studio Utwórz pierwszy projekt WinUI 3. Na przykład użyj szablonu projektu Blank App, Packaged (WinUI 3 in Desktop). Szablon projektu można znaleźć w oknie dialogowym Tworzenie nowego projektu, wybierając język: C# lub C++; platforma: zestaw SDK aplikacji systemu Windows; typ projektu: WinUI lub Desktop.

W eksploratorze rozwiązań zobaczysz dwa projekty— jeden jest kwalifikowany jako (desktop), a drugi jako (pakiet).

Najpierw przeprowadź migrację kodu z najmniejszą zależnością

Aby zilustrować to zalecenie, weźmy photolab case study jako przykład. W przypadku przykładowej aplikacji PhotoLab jednym z oczywistych podejść może być rozpoczęcie od migracji MainPage— ponieważ jest to tak ważny i istotny element aplikacji. Ale gdybyśmy to zrobili, wkrótce zdajemy sobie sprawę, że MainPage ma zależność od widoku DetailPage; a następnie DetailPage ma zależność od modelu Photo. Gdybyśmy podążali tą drogą, moglibyśmy stale przerywać siebie, przełączając się do pracy nad każdą nowo odkrytą zależnością. Z pewnością nie spodziewalibyśmy się, aby uzyskać czystą kompilację , dopóki nie uporamy się z każdą zależnością i zasadniczo przenieśli cały projekt jednym wielkim skokiem.

Gdybyśmy z drugiej strony mieli zacząć od części projektu, która nie zależy od niczego innego, i pracować na zewnątrz od tego punktu (od najmniej do najbardziej zależnej części), to bylibyśmy w stanie skupić się na każdej części po kolei. Będziemy również w stanie osiągnąć czystą budowę po migracji każdego z elementów i w ten sposób potwierdzić, że proces migracji pozostaje na właściwej drodze.

Dlatego podczas migrowania własnych aplikacji zalecamy najpierw migrację kodu z najmniejszą zależnością.

Czy skopiować pliki, czy skopiować zawartość pliku?

Podczas migracji będziesz oczywiście kopiować pliki zasobów (a nie zawartości pliku ). Ale co z plikami kodu źródłowego? Na przykład ponownie weźmy klasę MainPage z PhotoLab case study i Photo Editor case study.

C#. W wersji C# (PhotoLab) MainPage składa się z plików kodu źródłowego MainPage.xaml i MainPage.xaml.cs.

C++/WinRT. W wersji C++/WinRT (Edytor zdjęć) MainPage składa się z plików kodu źródłowego MainPage.xaml, MainPage.idl, MainPage.hi MainPage.cpp.

Możesz więc wybrać między tymi dwiema opcjami:

  • (Zalecane) możesz skopiować pliki (przy użyciu Eksploratora plików ), a następnie dodać kopie do projektu docelowego. Wyjątki od tego zalecenia to pliki, takie jak App.xaml i App.xaml.cs, ponieważ te pliki już istnieją w projekcie docelowym i zawierają kod źródłowy specyficzny dla zestawu SDK aplikacji systemu Windows. W przypadku tych elementów należy scalić kod źródłowy, który już tam istnieje, z kodem źródłowym z projektu źródłowego.
  • Możesz też użyć programu Visual Studio do utworzenia nowych plików strony (takich jak MainPage.xaml i MainPage.xaml.cs) w projekcie docelowym, a następnie skopiować zawartość tych plików kodu źródłowego z projektu źródłowego do projektu docelowego. W przypadku projektu C++/WinRT ta opcja obejmuje o wiele więcej kroków.

Zapoznaj się również z sekcją MainPage i MainWindow.

Różnice nazw folderów i plików (C++/WinRT)

W projekcie C++/WinRT UWP pliki code-behind dla widoków XAML są nazywane w formacie MainPage.h i MainPage.cpp. Jednak w zestawie SDK aplikacji systemu Windows w języku C++/WinRT należy zmienić ich nazwę na MainPage.xaml.h i MainPage.xaml.cpp.

W projekcie C++/WinRT UWP, podczas migrowania hipotetycznego widoku XAML (rozumianego jako model, widok oraz model widoku) o nazwie MyPage, w MyPage.xaml.cpp należy dodać #include "MyPage.g.cpp" natychmiast po #include "DetailPage.xaml.h". W przypadku hipotetycznego modelu o nazwie MyModel, w MyModel.cpp dodaj #include "MyModel.g.cpp" bezpośrednio po #include "MyModel.h". Dla przykładu, zobacz kod źródłowy Migrate DetailPage .

Jeśli zmienisz nazwę zmigrowanego projektu

Podczas migracji możesz nadać projektowi docelowemu inną nazwę od projektu źródłowego. W takim przypadku będzie to miało wpływ na domyślną przestrzeń nazw w projekcie źródłowym. Podczas kopiowania kodu źródłowego z projektu źródłowego do projektu docelowego może być konieczne zmiana nazw przestrzeni nazw wymienionych w kodzie źródłowym.

Zmiana nazwy projektu (a tym samym domyślnej nazwy przestrzeni nazw) jest czymś, co robimy na przykład w analizie przypadku , w migracji przykładowej aplikacji UWP PhotoLab (C#) przy użyciu zestawu SDK aplikacji systemu Windows. W tym przypadku zamiast kopiować zawartość pliku ze źródła do projektu docelowego, kopiujemy całe pliki przy użyciu Eksploratora plików. Nazwa źródłowego projektu/przestrzeni nazw to PhotoLab, a docelowa nazwa projektu/przestrzeni nazw to PhotoLabWinUI3. Dlatego musimy wyszukać PhotoLab w zawartości wszystkich skopiowanych plików kodu źródłowego i zmienić je na PhotoLabWinUI3

W tym konkretnym badaniu przypadku wprowadziliśmy te zmiany w App.xaml, App.xaml.cs, MainPage.xaml, MainPage.xaml.cs, DetailPage.xaml, DetailPage.xaml.cs, ImageFileInfo.csi LoadedImageBrush.cs.

Zainstaluj te same pakiety NuGet, które zostały zainstalowane w projekcie źródłowym

Jednym z zadań podczas procesu migracji jest zidentyfikowanie pakietów NuGet, od których zależy projekt źródłowy. Następnie zainstaluj te same pakiety NuGet w projekcie docelowym.

Na przykład, w badaniu przypadku dotyczącym migracji przykładowej aplikacji UWP PhotoLab (C#) w zestawie SDK aplikacji Windows, projekt źródłowy zawiera odwołania do pakietu NuGet Microsoft.Graphics.Win2D. W tym studium przypadku dodajemy odwołania do tego samego pakietu NuGet do projektu docelowego.