Converti APPX in XAP

Un dispositivo, un emulatore o uno strumento di distribuzione legacy Windows Phone 7 o 8 potrebbe richiedere un pacchetto XAP, mentre l'applicazione disponibile è un APPX. Questi pacchetti sono destinati a modelli applicativi diversi, quindi la modifica del nome del file o la conversione dell'archivio non può rendere l'APPX eseguibile come XAP.

Cos'è il formato APPX

APPX è un formato di pacchetto per applicazioni Windows utilizzato da Windows 8, Windows 10, Windows 11, Windows Phone 8.1 e dalle applicazioni basate su Universal Windows Platform. Gli sviluppatori lo creano con Visual Studio e gli strumenti Windows SDK; gli utenti lo incontrano durante l'installazione, la distribuzione o l'archiviazione delle applicazioni Windows.

Un APPX contiene normalmente un file AppxManifest.xml, file binari .NET o nativi compilati, risorse, dichiarazioni delle dipendenze, una block map facoltativa e una firma digitale. Il codice eseguibile è destinato a Windows Runtime, UWP o a un altro modello applicativo Windows supportato. Un APPX creato per Windows Phone 8.1 può utilizzare il modello Windows Phone Runtime, ma questo non lo rende uno XAP Silverlight.

Cos'è il formato XAP

XAP è un pacchetto di distribuzione basato su ZIP per applicazioni Microsoft Silverlight, incluse le applicazioni Windows Phone 7 e Windows Phone 8 e alcuni progetti phone Silverlight 8.1. Uno XAP phone può contenere assembly, risorse, un file AppManifest.xaml e dati del manifest specifici per phone, come WMAppManifest.xml.

I progetti legacy Windows Phone SDK generano file XAP durante la compilazione. I pacchetti XAP sono legati al runtime Silverlight phone, alla versione Windows Phone di destinazione, all'architettura del processore supportata e alle relative regole di firma e distribuzione. Windows Phone è fuori produzione e XAP non è un formato di installazione generico sulle piattaforme Windows o mobile attuali.

Come produrre un XAP

Non esiste un convertitore diretto affidabile da APPX a XAP. Uno XAP funzionante richiede un'applicazione phone Silverlight compilata con l'SDK legacy corretto, non semplicemente i file estratti da un APPX.

1. Identificare la destinazione richiesta. Determinare se il dispositivo richiede Windows Phone 7, Windows Phone 8 o un pacchetto Silverlight 8.1. Queste destinazioni richiedono SDK diversi e potrebbero non accettare i pacchetti destinati alle altre.
2. Recuperare il codice sorgente originale, se possibile. Se lo sviluppatore dispone di un progetto phone Silverlight, aprirlo con la versione legacy corrispondente di Visual Studio e Windows Phone SDK. Visual Studio 2010 è stato utilizzato per molti progetti Windows Phone 7, Visual Studio 2012 per Windows Phone 8 e Visual Studio 2013 per i progetti Silverlight Windows Phone 8.1.
3. Ispezionare l'APPX solo quando il codice sorgente non è disponibile. Windows SDK di Microsoft include makeappx.exe. Ad esempio, eseguire makeappx unpack /p Application.appx /d UnpackedApp, oppure aprire il pacchetto con 7-Zip. Questo espone manifest, risorse e file binari, ma non ricostruisce il progetto originale.
4. Eseguire manualmente il porting dell'applicazione. Creare o ripristinare un progetto Windows Phone Silverlight, quindi sostituire le API UWP o Windows Runtime, il codice del ciclo di vita dell'applicazione, le autorizzazioni, i controlli, le integrazioni dei servizi e le librerie incompatibili con gli equivalenti Silverlight phone. Aggiungere nuovamente le immagini recuperabili e gli altri asset.
5. Compilare il progetto di destinazione. Impostare la versione phone e l'architettura richieste, quindi scegliere Build → Build Solution. L'SDK legacy normalmente scrive lo XAP in una directory di output del progetto, come bin/Debug o bin/Release.
6. Applicare le impostazioni di firma e distribuzione richieste. Un pacchetto per una versione phone potrebbe non funzionare su un'altra; inoltre, il sideloading o la distribuzione tramite store possono richiedere certificati e impostazioni di developer-unlock specifici per quella piattaforma.

Nessun convertitore online affidabile può tradurre il modello eseguibile dell'APPX, le API, lo schema del manifest, le dipendenze e i requisiti di firma in uno XAP Silverlight. Gli strumenti online per gli archivi possono estrarre o ricomprimere i file, ma non possono eseguire questo porting dell'applicazione; inoltre, il caricamento di un pacchetto proprietario o firmato espone i suoi contenuti a terze parti.

Limitazioni di compatibilità

Rinominare Application.appx in Application.xap, modificare l'estensione ZIP o aggiungere AppManifest.xaml non cambia il formato eseguibile contenuto. Un file binario Windows Runtime, UWP o nativo proveniente da un APPX potrebbe essere incompatibile con il loader Silverlight, anche quando entrambi i pacchetti contengono assembly .NET.

Se l'APPX è l'unico file disponibile, è possibile recuperare immagini, testo e metadati e, occasionalmente, ispezionare gli assembly gestiti con strumenti di sviluppo appropriati, ma normalmente non è possibile recuperare il codice sorgente, la configurazione del progetto, le dipendenze originali o un comportamento XAP equivalente. Anche l'operazione inversa è un porting, non una conversione dell'archivio: uno XAP deve essere ricompilato per un modello applicativo Windows supportato prima di poter diventare un APPX.