Condividi tramite

Introduzione a .NET Native

Se stai scrivendo una nuova app UWP o eseguendo la migrazione di un'app Windows 8.x esistente (precedentemente denominata anche app di Microsoft Store), puoi seguire lo stesso set di procedure. Per creare un'app .NET Native, seguire questa procedura:

  1. Sviluppare un'app UWP (Universal Windows Platform) e testare le build di debug dell'app per assicurarsi che funzioni correttamente.

  2. Gestire l'utilizzo aggiuntivo di reflection e serializzazione.

  3. Distribuisci e testa le build di versione dell'app.

  4. Risolvere manualmente i metadati mancanti e ripetere il passaggio 3 fino a quando non vengono risolti tutti i problemi.

Annotazioni

Se stai eseguendo la migrazione di un'app Windows 8.x esistente a .NET Native, assicurati di esaminare Esegui la migrazione dell'app di Windows 8.x a .NET Native.

Passaggio 1: Sviluppare e testare le build di debug dell'app UWP

Sia che si stia sviluppando una nuova app o eseguendo la migrazione di un'app esistente, si segue lo stesso processo di qualsiasi app di Windows.

  1. Creare un nuovo progetto UWP in Visual Studio usando il modello di app di Windows universale per Visual C# o Visual Basic. Per impostazione predefinita, tutte le applicazioni UWP destinate a CoreCLR e le relative build di versione vengono compilate usando la catena di strumenti .NET Native.

  2. Si noti che esistono alcuni problemi di compatibilità noti tra la compilazione di progetti di app UWP con la catena di strumenti .NET Native e senza di essa. Per altre informazioni, vedere la guida alla migrazione .

Ora puoi scrivere codice in C# o Visual Basic nell'area di superficie .NET Native che gira sul sistema locale (o nel simulatore).

Importante

Durante lo sviluppo della tua app, prendi nota di qualsiasi uso della serializzazione o della riflessione nel codice.

Per impostazione predefinita, le build di debug vengono compilate tramite JIT per abilitare la distribuzione rapida tramite il tasto F5, mentre le build di versione vengono compilate usando la tecnologia di precompilazione .NET Native. Ciò significa che è necessario compilare e testare le build di debug dell'app per assicurarsi che funzionino normalmente prima di compilarle con la catena di strumenti .NET Native.

Passaggio 2: Gestire l'uso aggiuntivo di reflectione e serializzazione

Un file di direttive di runtime, Default.rd.xml, viene aggiunto automaticamente al progetto al momento della creazione. Se si sviluppa in C#, si trova nella cartella Proprietà del progetto. Se si sviluppa in Visual Basic, si trova nella cartella My Project del progetto.

Annotazioni

Per una panoramica del processo di compilazione .NET Native che fornisce informazioni generali sul motivo per cui è necessario un file di direttive di runtime, vedere .NET Native e Compilation.

Il file delle direttive di runtime viene usato per definire i metadati necessari per l'app in fase di esecuzione. In alcuni casi, la versione predefinita del file potrebbe essere adeguata. Tuttavia, alcuni codici che si basano sulla serializzazione o riflessione possono richiedere voci aggiuntive nel file delle direttive di runtime.

serializzazione

Esistono due categorie di serializzatori ed entrambi possono richiedere voci aggiuntive nel file delle direttive di runtime:

  • Serializzatori non basati sulla reflection. I serializzatori trovati nella libreria di classi del .NET Framework, come le classi DataContractSerializer, DataContractJsonSerializere XmlSerializer, non si basano sulla reflection. Tuttavia, richiedono che il codice venga generato in base all'oggetto da serializzare o deserializzare. Per ulteriori informazioni, vedere la sezione "Serializzatori Microsoft" in Serializzazione e Metadata.

  • Serializzatori di terze parti. Le librerie di serializzazione di terze parti, la più comune delle quali è il serializzatore JSON Newtonsoft, sono in genere basate sulla reflection e richiedono voci nel file *.rd.xml per supportare la serializzazione e la deserializzazione degli oggetti. Per altre informazioni, vedere la sezione "Serializzatori di terze parti" in Serializzazione e Metadati.

Metodi che si basano sulla riflessione

In alcuni casi, l'uso della riflessione nel codice non è ovvio. Alcune API o modelli di programmazione comuni non sono considerati parte dell'API di riflessione, ma si basano sulla riflessione per eseguire con successo. Sono inclusi i seguenti metodi di creazione di istanze di tipi e di costruzione di metodi:

Per altre informazioni, vedere API che si basano sulla reflection.

Annotazioni

I nomi dei tipi usati nei file delle direttive di runtime devono essere completamente qualificati. Ad esempio, il file deve specificare "System.String" anziché "String".

Passaggio 3: Distribuire e testare le versioni di build della tua app

Dopo avere aggiornato il file delle direttive di runtime, è possibile ricompilare e distribuire le versioni di rilascio dell'app. I file binari .NET Native vengono inseriti nella sottodirectory ILC.out della directory specificata nella casella di testo percorso di output Build della finestra di dialogo Proprietà del progetto, nella scheda Compilazione. I file binari che non si trovano in questa cartella non sono stati compilati con .NET Native. Testare attentamente l'app e testare tutti gli scenari, inclusi gli scenari di errore, in ognuna delle piattaforme di destinazione.

Se l'app non funziona correttamente (in particolare nei casi in cui genera eccezioni MissingMetadataException o MissingInteropDataException in fase di esecuzione), seguire le istruzioni nella sezione successiva, passaggio 4: risolvere manualmente i metadati mancanti. Attivare le eccezioni first-chance può aiutarti a trovare questi bug.

Dopo aver testato e sottoposto a debug le build di debug dell'app e sei certo di aver eliminato le eccezioni MissingMetadataException e MissingInteropDataException, è consigliabile testare l'app ottimizzata come app .NET Native. A tale scopo, modificare la configurazione del progetto attiva da Debug a Rilascio.

Passaggio 4: Risolvere manualmente i metadati mancanti

L'errore più comune che incontrerai con .NET Native e che non riscontri sul desktop è un'eccezione di runtime MissingMetadataException, MissingInteropDataExceptiono MissingRuntimeArtifactException. In alcuni casi, l'assenza di metadati può manifestarsi in un comportamento imprevedibile o anche in errori dell'app. In questa sezione viene illustrato come eseguire il debug e risolvere queste eccezioni aggiungendo direttive al file delle direttive di runtime. Per informazioni sul formato delle direttive di runtime, vedere Direttive di runtime (rd.xml) Riferimento al file di configurazione. Dopo aver aggiunto le direttive di runtime, è necessario distribuire e testare di nuovo l'app e risolvere eventuali nuove eccezioni MissingMetadataException, MissingInteropDataExceptione MissingRuntimeArtifactException eccezioni finché non si verificano altre eccezioni.

Suggerimento

Specificare le direttive di runtime a un livello generale per consentire all'app di essere resiliente alle modifiche al codice. È consigliabile aggiungere direttive di runtime a livello di spazio dei nomi e tipi anziché a livello di membro. Si noti che potrebbe esserci un compromesso tra resilienza e file binari più grandi con tempi di compilazione più lunghi.

Quando si affronta un'eccezione di metadati mancanti, considerare questi problemi:

  • Cosa stava cercando di fare l'app prima dell'eccezione?

    • Ad esempio, si trattava di data binding, serializzazione o deserializzazione dei dati, oppure dell'uso diretto dell'API di Reflection?

  • Si tratta di un caso isolato o si ritiene che si verifichi lo stesso problema per altri tipi?

    • Ad esempio, viene generata un'eccezione MissingMetadataException durante la serializzazione di un tipo nel modello di oggetti dell'app. Se si conoscono altri tipi che verranno serializzati, è possibile aggiungere direttive di runtime per tali tipi (o per i relativi nomi dei namespace, in base all'organizzazione del codice).

  • Puoi riscrivere il codice in modo che non utilizzi la reflection?

    • Ad esempio, il codice usa la dynamic parola chiave quando si conosce il tipo da aspettarsi?

    • Il codice chiama un metodo che dipende dalla riflessione quando è disponibile un'alternativa migliore?

Annotazioni

Per ulteriori informazioni sulla gestione dei problemi derivanti dalle differenze nella reflection e sulla disponibilità dei metadati nelle app desktop e in .NET Native, vedere le API che dipendono dalla reflection.

Per alcuni esempi specifici di gestione delle eccezioni e altri problemi che si verificano durante il test dell'app, vedere:

Vedere anche

  • Last updated on