Introduzione di .NET Native

  • Articolo

Indipendentemente dal fatto che tu stia 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 una nuova app .NET Native, effettuare i seguenti passaggi:

  1. Sviluppare un'app UWP (Universal Windows Platform), e testare le build di debug dell'app per verificarne il corretto funzionamento.

  2. Gestire la reflection aggiuntiva e l'uso della serializzazione.

  3. Distribuire e testare le build di rilascio dell'app.

  4. Risolvere manualmente i metadati mancantie ripetere il passaggio 3 finché non vengono risolti tutti i problemi.

Nota

Se si sta migrando un'app esistente di Windows 8.x app a .NET Native, consultare Migrating Your Windows 8.x App to .NET Native.

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

Per sviluppare una nuova app ed eseguire la migrazione di un'app esistente, si segue lo stesso processo usato per una qualsiasi app di Windows.

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

  2. Sono presenti alcuni problemi noti di compatibilità tra i progetti di app UWP compilati con o senza la catena di strumenti .NET Native. Per altre informazioni, vedere la guida alla migrazione .

Ora è possibile scrivere codice C# o Visual Basic rispetto alla superficie di attacco .NET Native da eseguire nel sistema locale (o nel simulatore).

Importante

Quando si sviluppa l'app, annotare qualsiasi uso di serializzazione o reflection nel codice.

Per impostazione predefinita, le compilazioni di debug vengono compilate tramite JIT per consentirne la distribuzione rapida tramite F5, mentre le compilazioni di rilascio vengono compilate usando la tecnologia di precompilazione .NET Native . Quindi, è necessario compilare e testare le build di debug dell'app per verificarne il normale funzionamento prima di compilarle con la catena di strumenti .NET Native.

Passaggio 2: Gestire l'uso aggiuntivo della reflection e della serializzazione

Default.rd.xml, il file di direttive di runtime, aggiunto automaticamente al progetto al momento della creazione, si trova nella cartella Proprietà del progetto se si sviluppa in C#, nella cartella Progetto personale del progetto se si sviluppa in Visual Basic.

Nota

Per una panoramica del processo di compilazione di .NET Native e informazioni di base sui motivi per cui è necessario un file di direttive di runtime, vedere Compilazione e .NET Native.

Il file di direttive di runtime viene usato per definire i metadati necessari all'app in fase di esecuzione. In alcuni casi, la versione predefinita del file potrebbe essere sufficiente. Tuttavia, il codice che si basa sulla serializzazione o la reflection potrebbe richiedere voci aggiuntive nei file di direttive di runtime.

Serializzazione

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

  • Serializzatori non basati sulla reflection. I serializzatori nella libreria di classi .NET Framework, ad esempio 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 altre informazioni, vedere la sezione "Serializzatori Microsoft" in Serialization and Metadata.

  • Serializzatori di terze parti. Le librerie di serializzazione di terze parti, la più nota delle quali è il serializzatore JSON di NewtonSoft, sono generalmente basate sulla reflection e richiedono delle 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 Serialization and Metadata.

Metodi basati sulla reflection

In alcuni casi, l'uso della reflection nel codice non è scontato. Alcuni modelli di programmazione o API comuni non sono considerati parte dell'API di reflection ma si basano sulla reflection per una corretta esecuzione Sono inclusi i seguenti metodi di creazione di un'istanza del tipo di costruzione del metodo:

Per altre informazioni, vedere APIs That Rely on Reflection.

Nota

I nomi dei tipi usati nei file di direttive di runtime devono essere completi. Ad esempio, il file deve specificare "System.String" invece di "String".

Passaggio 3: Distribuire e testare le build di rilascio dell'app

Dopo aver aggiornato il file delle direttive di runtime, è possibile ricompilare e distribuire le build di versione dell'app. i file binari .NET Native vengono inseriti nella sottodirectory ILC.out della directory specificata nella casella di testo Percorso di output della finestra di dialogo Proprietà del progetto, la scheda Compila . I file binari che non si trovano in questa cartella non sono stati compilati con .NET Native. Testare accuratamente l'app e tutti gli scenari, inclusi gli scenari di errore, in ogni piattaforma di destinazione.

Se l'app non funziona correttamente (in particolare se genera eccezioni MissingMetadataException o MissingInteropDataException in runtime), seguire le istruzioni della sezione successiva Passaggio 4: Risolvere manualmente i metadati mancanti. L'abilitazione di eccezioni first-chance aiuta a individuare i bug.

Dopo aver testato ed eseguito il debug delle build di debug dell'app e quando si è certi di aver eliminato le eccezioni MissingMetadataException e MissingInteropDataException , testare l'app come app ottimizzata per .NET Native. Per eseguire questa operazione, modificare la configurazione del progetto attiva da Debug a Rilascio.

Passaggio 4: Risolvere manualmente i metadati mancanti

L'errore più comune riscontrato con .NET Native che non viene rilevato sul desktop è un'eccezione MissingMetadataException, MissingInteropDataException, o MissingRuntimeArtifactException. In alcuni casi, l'assenza di metadati può causare un comportamento imprevisto o anche errori dell'app. In questa sezione viene descritto come eseguire il debug e risolvere tali eccezioni aggiungendo delle direttive al file di direttive di runtime. Per informazioni sul formato delle direttive di runtime, vedere Informazioni di riferimento sul file di configurazione delle direttive di runtime (rd.xml). Dopo aver aggiunto le direttive di runtime, è necessario distribuire e testare di nuovo l'app e risolvere eventuali nuove eccezioni MissingMetadataException, MissingInteropDataExceptione MissingRuntimeArtifactException fino a quando non si verificano altre eccezioni.

Suggerimento

Specificare le direttive di runtime a un alto livello per rendere l'app adattabile alle modifiche del codice. Si consiglia di aggiungere le direttive di runtime a livello degli spazi dei nomi e dei tipi e non a livello dei membri. Potrebbe essere necessario un compromesso tra resilienza, file binari di grandi dimensioni e tempi di compilazione più lunghi.

Quando si risolve un'eccezione relativa a metadati mancanti, prendere in considerazione quanto segue:

  • Che cosa stava tentando di eseguire l'app prima dell'eccezione?

    • Ad esempio, stava eseguendo il data binding, la serializzazione o la deserializzazione dei dati o usando direttamente l'API reflection?

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

    • Ad esempio, un'eccezione MissingMetadataException viene generata durante la serializzazione di un tipo nel modello a oggetti dell'app. Se si conoscono gli altri tipi da serializzare, è possibile aggiungere contemporaneamente le direttive di runtime per questi tipi (o per gli spazi dei nomi che li contengono, a seconda di quanto efficacemente è organizzato il codice).

  • Il codice può essere riscritto per escludere l'uso della reflection?

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

    • Il codice chiama un metodo basato sulla reflection quando è disponibile un'alternativa migliore?

Nota

Per altre informazioni sulla gestione dei problemi derivanti dalle differenze relative alla reflection e alla disponibilità dei metadati nelle app desktop e .NET Native, vedere APIs That Rely on Reflection.

Per alcuni esempi specifici di gestione delle eccezioni e di altri problemi relativi ai test dell'app, vedere:

Vedi anche