Conversione di progetti Di Windows Phone Silverlight in progetti UWP

L'argomento precedente era Namespace e mapping di classi.

Per iniziare il processo di conversione, creare un nuovo progetto Windows 10 in Visual Studio e copiarvi i file.

Creare il progetto e copiarvi i file

1. Avviare Microsoft Visual Studio 2015 e creare un nuovo progetto Applicazione vuota (Windows Universal). Per altre info, vedere Guida introduttiva all'app Windows Runtime 8.x con i modelli (C#, C++, Visual Basic). Il nuovo progetto compila un pacchetto dell'app (un file appx) che verrà eseguito in tutte le famiglie di dispositivi.
2. Nel progetto di app di Windows Phone Silverlight identificare tutti i file di codice sorgente e i file di asset visivi da riutilizzare. Usando Esplora file, copiare modelli di dati, visualizzare modelli, asset visivi, dizionari risorse, struttura di cartelle e qualsiasi altro elemento da riutilizzare nel nuovo progetto. Copiare o creare sottocartelle su disco in base alle esigenze.
3. Copiare anche le visualizzazioni (ad esempio MainPage.xaml e MainPage.xaml.cs) nel nuovo nodo del progetto. Anche in questo caso, creare nuove sottocartelle in base alle esigenze e rimuovere le visualizzazioni esistenti dal progetto. Tuttavia, prima di sovrascrivere o rimuovere una visualizzazione generata da Visual Studio, mantenere una copia perché può essere utile farvi riferimento in un secondo momento. La prima fase della conversione di un'app Windows Phone Silverlight è incentrata su come ottenere un aspetto ottimale e funzionare bene in una famiglia di dispositivi. Successivamente, si rivolgerà l'attenzione per assicurarsi che le visualizzazioni si adattino bene a tutti i fattori di forma e, facoltativamente, per aggiungere qualsiasi codice adattivo per ottenere il massimo da una particolare famiglia di dispositivi.
4. In Esplora soluzioni assicurarsi che l'opzione Mostra tutti i file sia attivata. SElezionare i file di copiati, fare clic con il tasto destro del mouse su di essi, quindi fare clic su Includi nel progetto. Questo includerà automaticamente le cartelle contenenti. È quindi possibile disattivare Mostra tutti i file se lo si desidera. Un flusso di lavoro alternativo, se si preferisce, consiste nell'usare il comando Aggiungi elemento esistente, dopo aver creato eventuali sottocartelle necessarie in Visual Studio Esplora soluzioni. Verificare che gli asset visivi abbiano Azione di compilazione impostata a Contenuto e Copia in directory in uscita impostato su Non copiare.
5. Le differenze nei nomi di spazio dei nomi e classi genereranno molti errori di compilazione in questa fase. Ad esempio, se si aprono le visualizzazioni generate da Visual Studio, si noterà che sono di tipo Page e non PhoneApplicationPage. Ci sono molte differenze di markup XAML e codice imperativo che gli argomenti seguenti in questa guida alla conversione illustrano in dettaglio. Tuttavia, si procederà rapidamente seguendo questi passaggi generali: modificare "clr-namespace" in "using" nelle dichiarazioni di prefisso dello spazio dei nomi nel markup XAML; usare l'argomento Mapping di spazi dei nomi e classi e il comando Trova e sostituisci di Visual Studio per apportare modifiche in blocco al codice sorgente, ad esempio sostituire "System.Windows" con "Windows.UI.Xaml" e nell'editor di codice imperativo in Visual Studio usare i comandi Risolvi e Organizza using nel menu di scelta rapida per modifiche più mirate.

SDK di estensione

La maggior parte delle API piattaforma UWP (Universal Windows Platform) che verrà chiamata dall'app con conversione viene implementata nel set di API note come famiglia di dispositivi universali. Tuttavia, alcuni vengono implementati negli SDK di estensione e Visual Studio riconosce solo le API implementate dalla famiglia di dispositivi di destinazione dell'app o da qualsiasi SDK di estensione a cui si è fatto riferimento.

Se vengono visualizzati errori di compilazione relativi a spazi dei nomi o tipi o membri che non sono stati trovati, è probabile che questa sia la causa. Aprire l'argomento dell'API nella documentazione di riferimento dell'API e passare alla sezione Requisiti: che indicherà qual è la famiglia di dispositivi di implementazione. Se non è la famiglia di dispositivi di destinazione, per rendere disponibile l'API per il progetto, è necessario un riferimento all'SDK di estensione per la famiglia di dispositivi.

Fare clic su Progetto>Aggiungi riferimento>Windows Universal>Estensioni e selezionare l'SDK di estensione appropriato. Ad esempio, se le API che si desidera chiamare sono disponibili solo nella famiglia di dispositivi mobili e sono state introdotte nella versione 10.0.x.y, selezionare Estensioni di Windows Mobile per la piattaforma UWP.

Questo aggiungerà il riferimento seguente al file di progetto:

<ItemGroup>
    <SDKReference Include="WindowsMobile, Version=10.0.x.y">
        <Name>Windows Mobile Extensions for the UWP</Name>
    </SDKReference>
</ItemGroup>

Il nome e il numero di versione corrispondono alle cartelle nel percorso installato dell'SDK. Ad esempio, le informazioni precedenti corrispondono a questo nome di cartella:

\Program Files (x86)\Windows Kits\10\Extension SDKs\WindowsMobile\10.0.x.y

A meno che l'app non sia destinata alla famiglia di dispositivi che implementa l'API, si dovrà usare la classe ApiInformation per verificare la presenza dell'API prima di chiamarla (questo è detto codice adattivo). Questa condizione verrà quindi valutata ovunque venga eseguita l'app, ma valuterà true solo nei dispositivi in cui l'API è presente e quindi disponibile per essere chiamata. Usare gli SDK di estensione e il codice adattivo solo dopo aver verificato se esiste un'API universale. Alcuni esempi sono riportati nella sezione seguente.

Vedere anche Manifesto del pacchetto dell'app.

Ottimizzazione del markup e del riutilizzo del codice

Si scoprirà che il refactoring di un p ' e/o l'aggiunta di codice adattivo (illustrato di seguito), consentirà di ottimizzare il markup e il codice che funziona in tutte le famiglie di dispositivi. Di seguito sono riportate informazioni dettagliate.

• I file comuni a tutte le famiglie di dispositivi non necessitano di considerazioni speciali. Questi file verranno usati dall'app in tutte le famiglie di dispositivi in cui viene eseguito. Sono inclusi i file di markup XAML, i file di codice sorgente imperativo e i file di asset.
• È possibile che l'app rilevi la famiglia di dispositivi su cui è in esecuzione e passi a una visualizzazione progettata appositamente per la famiglia di dispositivi. Per altri dettagli, vedere Rilevamento della piattaforma in cui è in esecuzione l'app.
• Una tecnica simile che può risultare utile se non esiste un'alternativa consiste nell'assegnare un file di markup o un file ResourceDictionary (o la cartella che contiene il file) un nome speciale in modo che venga caricato automaticamente in fase di esecuzione solo quando l'app viene eseguita in una determinata famiglia di dispositivi. Questa tecnica è illustrata nel case study Bookstore1.
• Per usare le funzionalità non disponibili in tutte le famiglie di dispositivi (ad esempio stampanti, scanner o pulsante della fotocamera) è possibile scrivere codice adattivo. Vedere il terzo esempio in Compilazione condizionale e codice adattivo in questo argomento.
• Se si vuole supportare sia Windows Phone Silverlight che Windows 10, si potrebbe essere in grado di condividere file di codice sorgente tra progetti. Ecco come: in Visual Studio fare clic con il pulsante destro del mouse sul progetto in Solution Explorer, selezionare Aggiungi elemento esistente, selezionare i file da condividere e quindi fare clic su Aggiungi come collegamento. Archiviare i file del codice sorgente in una cartella comune nel file system in cui i progetti collegati possono visualizzarli e non dimenticare di aggiungerli al controllo del codice sorgente. Se è possibile considerare il codice sorgente imperativo in modo che la maggior parte, se non tutti, di un file funzioni su entrambe le piattaforme, non è necessario disporre di due copie di esso. È possibile eseguire il wrapping di qualsiasi logica specifica della piattaforma nel file all'interno di direttive di compilazione condizionale, se possibile, o condizioni di runtime, se necessario. Vedere la sezione seguente e le direttive del preprocessore C#.
• Per il riutilizzo a livello binario, anziché a livello di codice sorgente, sono disponibili librerie di classi portabili, che supportano il subset di API .NET disponibili in Windows Phone Silverlight, nonché il subset per le app di Windows 10 (.NET Core). I gruppi della libreria di classi portabili sono compatibili con queste piattaforme .NET e molto altro. Usare Visual Studio per creare un progetto destinato a una libreria di classi portabile. Vedere Sviluppo multipiattaforma con la libreria di classi portabile.

Compilazione condizionale e codice adattivo

Se si vuole supportare sia Windows Phone Silverlight che Windows 10 in un singolo file di codice, si può farlo. Se si guarda il progetto di Windows 10 nelle pagine delle proprietà del progetto, si vedrà che il progetto definisce WINDOWS_UAP come simbolo di compilazione condizionale. In generale, è possibile usare la logica seguente per eseguire la compilazione condizionale.

#if WINDOWS_UAP
    // Code that you want to compile into the Windows 10/11 app.
#else
    // Code that you want to compile into the Windows Phone Silverlight app.
#endif // WINDOWS_UAP

Se si ha codice che si è condiviso tra un'app Windows Phone Silverlight e un'app Windows Runtime 8.x, si potrebbe avere già codice sorgente con logica simile alla seguente:

#if NETFX_CORE
    // Code that you want to compile into the Windows Runtime 8.x app.
#else
    // Code that you want to compile into the Windows Phone Silverlight app.
#endif // NETFX_CORE

In tal caso, e se ora si vuole supportare Windows 10 in aggiunta, si può farlo.

#if WINDOWS_UAP
    // Code that you want to compile into the Windows 10/11 app.
#else
#if NETFX_CORE
    // Code that you want to compile into the Windows Runtime 8.x app.
#else
    // Code that you want to compile into the Windows Phone Silverlight app.
#endif // NETFX_CORE
#endif // WINDOWS_UAP

È possibile che sia stata usata la compilazione condizionale per limitare la gestione del pulsante Indietro hardware a Windows Phone. In Windows 10, l'evento pulsante Indietro è un concetto universale. I pulsanti Indietro implementati nell'hardware o nel software generano tutti l'evento BackRequested, in modo che sia quello da gestire.

       Windows.UI.Core.SystemNavigationManager.GetForCurrentView().BackRequested +=
            this.ViewModelLocator_BackRequested;

...

    private void ViewModelLocator_BackRequested(object sender, Windows.UI.Core.BackRequestedEventArgs e)
    {
        // Handle the event.
    }

È possibile che sia stata usata la compilazione condizionale per limitare la gestione del pulsante fotocamera hardware a Windows Phone. In Windows 10 il pulsante della fotocamera hardware è un concetto particolare per la famiglia di dispositivi mobili. Poiché un pacchetto dell'app verrà eseguito in tutti i dispositivi, la condizione in fase di compilazione viene modificata in una condizione di runtime usando il nome di codice adattivo. A tale scopo, usiamo la classe ApiInformation per eseguire query in fase di esecuzione per la presenza della classe HardwareButtons. HardwareButtons è definito nell'SDK dell'estensione per dispositivi mobili, quindi è necessario aggiungere un riferimento a tale SDK al progetto per la compilazione di questo codice. Si noti, tuttavia, che il gestore verrà eseguito solo in un dispositivo che implementa i tipi definiti nell'SDK dell'estensione per dispositivi mobili ed è la famiglia di dispositivi mobili. Di conseguenza, il codice seguente è attento solo all'uso di funzionalità presenti, anche se viene ottenuto in modo diverso dalla compilazione condizionale.

       // Note: Cache the value instead of querying it more than once.
        bool isHardwareButtonsAPIPresent = Windows.Foundation.Metadata.ApiInformation.IsTypePresent
            ("Windows.Phone.UI.Input.HardwareButtons");

        if (isHardwareButtonsAPIPresent)
        {
            Windows.Phone.UI.Input.HardwareButtons.CameraPressed +=
                this.HardwareButtons_CameraPressed;
        }

    ...

    private void HardwareButtons_CameraPressed(object sender, Windows.Phone.UI.Input.CameraEventArgs e)
    {
        // Handle the event.
    }

Inoltre, vedere Rilevamento della piattaforma in cui è in esecuzione l'app.

Manifesto del pacchetto dell'app

Le impostazioni nel progetto (inclusi i riferimenti agli SDK di estensione) determinano la superficie di attacco dell'API che l'app può chiamare. Tuttavia, il manifesto del pacchetto dell'app è ciò che determina il set effettivo di dispositivi in cui i clienti possono installare l'app dallo Store. Per altre info, vedere Esempi in TargetDeviceFamily.

Vale la pena sapere come modificare il manifesto del pacchetto dell'app, perché gli argomenti che seguono parlano di usarlo per varie dichiarazioni, funzionalità e altre impostazioni necessarie per alcune funzionalità. È possibile usare l'editor del manifesto del pacchetto dell'app di Visual Studio per modificarlo. Se Esplora soluzioni non viene visualizzato, selezionarlo dal menu Visualizza. Fare doppio clic su Package.appxmanifest. Verrà visualizzata la finestra dell'editor del manifesto. Selezionare la scheda appropriata per apportare modifiche e quindi salvare le modifiche. È possibile assicurarsi che l'elemento pm:PhoneIdentity nel manifesto dell'app convertito corrisponda a quello che si trova nel manifesto dell'app che stai eseguendo la conversione (per informazioni dettagliate, vedere l'argomento pm:PhoneIdentity).

Vedere Riferimento dello schema del manifesto del pacchetto per Windows 10.

L'argomento successivo è Risoluzione dei problemi.