Konwertuj APPX na XAP

Starsze urządzenie Windows Phone 7 lub 8, emulator albo narzędzie wdrażania może wymagać pakietu XAP, podczas gdy dostępna aplikacja jest pakietem APPX. Pakiety te są przeznaczone dla różnych modeli aplikacji, dlatego zmiana nazwy pliku ani konwersja archiwum nie sprawi, że APPX będzie można uruchomić jako XAP.

Czym jest format APPX

APPX to format pakietu aplikacji Windows używany przez Windows 8, Windows 10, Windows 11, Windows Phone 8.1 oraz aplikacje oparte na Universal Windows Platform. Deweloperzy tworzą go za pomocą Visual Studio i narzędzi Windows SDK; użytkownicy mają z nim styczność podczas instalowania, dystrybuowania lub archiwizowania aplikacji Windows.

Pakiet APPX zwykle zawiera plik AppxManifest.xml, skompilowane pliki binarne .NET lub natywne, zasoby, deklaracje zależności, opcjonalną mapę bloków oraz podpis cyfrowy. Jego kod wykonywalny jest przeznaczony dla Windows Runtime, UWP lub innego obsługiwanego modelu aplikacji Windows. Pakiet APPX utworzony dla Windows Phone 8.1 może korzystać z modelu Windows Phone Runtime, ale nie czyni go to pakietem Silverlight XAP.

Czym jest format XAP

XAP to oparty na ZIP pakiet wdrożeniowy aplikacji Microsoft Silverlight, w tym aplikacji Windows Phone 7 i Windows Phone 8 oraz niektórych projektów telefonu Silverlight 8.1. Pakiet XAP telefonu może zawierać zestawy, zasoby, plik AppManifest.xaml oraz dane manifestu specyficzne dla telefonu, takie jak WMAppManifest.xml.

Projekty Legacy Windows Phone SDK generują pliki XAP podczas kompilacji. Pakiety XAP są powiązane z środowiskiem wykonawczym Silverlight telefonu, docelową wersją Windows Phone, obsługiwaną architekturą procesora oraz odpowiednimi regułami podpisywania i wdrażania. System Windows Phone został wycofany, a XAP nie jest ogólnym formatem instalacyjnym we współczesnych systemach Windows ani na platformach mobilnych.

Jak utworzyć pakiet XAP

Nie istnieje niezawodny bezpośredni konwerter APPX-to-XAP. Działający pakiet XAP wymaga aplikacji telefonu Silverlight zbudowanej przy użyciu odpowiedniego Legacy SDK, a nie tylko plików wyodrębnionych z APPX.

1. Określ wymagany cel. Ustal, czy urządzenie wymaga pakietu dla Windows Phone 7, Windows Phone 8 czy Silverlight 8.1. Te cele wymagają różnych SDK i mogą nie akceptować wzajemnie swoich pakietów.
2. Odzyskaj oryginalny kod źródłowy, jeśli to możliwe. Jeśli deweloper ma projekt telefonu Silverlight, otwórz go za pomocą pasującej wersji Legacy Visual Studio i Windows Phone SDK. Visual Studio 2010 było używane w wielu projektach Windows Phone 7, Visual Studio 2012 w projektach Windows Phone 8, a Visual Studio 2013 w projektach Silverlight Windows Phone 8.1.
3. Przeanalizuj APPX tylko wtedy, gdy kod źródłowy jest niedostępny. Windows SDK firmy Microsoft zawiera program makeappx.exe. Możesz na przykład uruchomić polecenie makeappx unpack /p Application.appx /d UnpackedApp albo otworzyć pakiet za pomocą 7-Zip. Umożliwia to dostęp do manifestów, zasobów i plików binarnych, ale nie odtwarza oryginalnego projektu.
4. Przenieś aplikację ręcznie. Utwórz lub przywróć projekt Windows Phone Silverlight, a następnie zastąp interfejsy API UWP lub Windows Runtime, kod cyklu życia aplikacji, uprawnienia, kontrolki, integracje z usługami oraz niezgodne biblioteki ich odpowiednikami dla Silverlight telefonu. Dodaj ponownie możliwe do odzyskania obrazy i inne zasoby.
5. Zbuduj projekt docelowy. Ustaw wymaganą wersję telefonu i architekturę, a następnie wybierz Build → Build Solution. Legacy SDK zwykle zapisuje pakiet XAP w katalogu wyjściowym projektu, takim jak bin/Debug lub bin/Release.
6. Zastosuj wymagane ustawienia podpisywania i wdrażania. Pakiet dla jednej wersji telefonu może nie działać na innej, a sideloading lub wdrażanie ze sklepu może wymagać certyfikatów i ustawień odblokowania deweloperskiego specyficznych dla danej platformy.

Żaden renomowany konwerter online nie potrafi przetłumaczyć modelu pliku wykonywalnego APPX, interfejsów API, schematu manifestu, zależności i wymagań dotyczących podpisywania na pakiet Silverlight XAP. Narzędzia online do obsługi archiwów mogą wyodrębniać lub ponownie kompresować pliki, ale nie mogą wykonać takiego przeniesienia aplikacji; przesłanie własnościowego lub podpisanego pakietu ujawnia również jego zawartość stronie trzeciej.

Ograniczenia zgodności

Zmiana nazwy Application.appx na Application.xap, zmiana rozszerzenia ZIP lub dodanie pliku AppManifest.xaml nie zmienia formatu pliku wykonywalnego znajdującego się w pakiecie. Plik binarny Windows Runtime, UWP lub natywny pochodzący z APPX może być niezgodny z modułem ładującym Silverlight, nawet jeśli oba pakiety zawierają zestawy .NET.

Jeśli APPX jest jedynym dostępnym plikiem, można odzyskać obrazy, tekst, metadane i czasami przeanalizować zarządzane zestawy za pomocą odpowiednich narzędzi deweloperskich, ale zazwyczaj nie można odzyskać kodu źródłowego, konfiguracji projektu, oryginalnych zależności ani równoważnego działania XAP. Operacja odwrotna również jest przeniesieniem, a nie konwersją archiwum: pakiet XAP musi zostać przebudowany dla obsługiwanego modelu aplikacji Windows, zanim będzie można przekształcić go w APPX.