Nota:
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
Importante
Modernize tu aplicación para UWP con .NET y AOT nativo: si estás desarrollando una nueva aplicación para UWP o quieres modernizar una aplicación para UWP existente, te recomendamos usar UWP compatible con la última .NET con AOT nativo en lugar de .NET Native. La compatibilidad con UWP para .NET moderna ahora está disponible con carácter general y es el tipo de proyecto default para aplicaciones para UWP de C# en Visual Studio 2026. Esto proporciona acceso a las últimas características de .NET y C#, mejoras en las herramientas y soporte de depuración, y tiempos de compilación más rápidos. .NET Native seguirá recibiendo correcciones de seguridad y confiabilidad, pero no recibirá nuevas actualizaciones de características.
Tanto si estás escribiendo una nueva aplicación para UWP como si vas a migrar una aplicación de Windows 8.x existente (anteriormente denominada también aplicación de Microsoft Store), puedes seguir el mismo conjunto de procedimientos. Para crear una aplicación nativa de .NET, siga estos pasos:
Desarrollar una aplicación de Plataforma universal de Windows (UWP) y probar las compilaciones de depuración de la aplicación para asegurarse de que funciona correctamente.
Manejo del uso adicional de la reflexión y la serialización.
Implementar y probar las versiones de lanzamiento de la aplicación.
Resolver manualmente los metadatos que faltany repetir paso 3 hasta que se resuelvan todos los problemas.
Nota:
Si va a migrar una aplicación de Windows 8.x existente a .NET Native, asegúrese de revisar Migrando la aplicación Windows 8.x a .NET Native.
Paso 1: Desarrollar y probar compilaciones de depuración de su aplicación UWP
Tanto si está desarrollando una nueva aplicación como si va a migrar una existente, siga el mismo proceso que para cualquier aplicación de Windows.
Cree un nuevo proyecto para UWP en Visual Studio mediante la plantilla de aplicación de Windows universal para Visual C# o Visual Basic. De forma predeterminada, todas las aplicaciones para UWP tienen como destino CoreCLR y sus compilaciones de versión se compilan mediante la cadena de herramientas nativas de .NET.
Ten en cuenta que hay algunos problemas de compatibilidad conocidos entre la compilación de proyectos de aplicaciones para UWP con la cadena de herramientas nativa de .NET y sin ella. Consulte la guía de migración de para obtener más información.
Ahora puede escribir código en C# o Visual Basic para el entorno .NET Native que se ejecuta en el sistema local (o en el simulador).
Importante
A medida que desarrolle la aplicación, tenga en cuenta cualquier uso de la serialización o reflexión en el código.
De forma predeterminada, los builds de depuración se compilan con JIT para habilitar la implementación rápida de F5, mientras que los builds de liberación se compilan mediante la tecnología .NET Native de precompilación. Esto significa que debes compilar y probar las compilaciones de depuración de la aplicación para asegurarte de que funcionan normalmente antes de compilarlas con la cadena de herramientas nativa de .NET.
Paso 2: Control del uso adicional de reflexión y serialización
Un archivo de directivas en tiempo de ejecución, Default.rd.xml, se agrega automáticamente al proyecto al crearlo. Si desarrollas en C#, se encuentra en la carpeta Propiedades del proyecto. Si desarrolla en Visual Basic, se encuentra en la carpeta My Project de su proyecto.
Nota:
Para obtener información general sobre el proceso de compilación nativo de .NET que proporciona información general sobre por qué se necesita un archivo de directivas en tiempo de ejecución, consulte .NET Native and Compilation.
El archivo de directivas en tiempo de ejecución se usa para definir los metadatos que la aplicación necesita en tiempo de ejecución. En algunos casos, la versión predeterminada del archivo puede ser adecuada. Sin embargo, algunos código que se basa en la serialización o reflexión pueden requerir entradas adicionales en el archivo de directivas en tiempo de ejecución.
Serialización de
Hay dos categorías de serializadores y ambas pueden requerir entradas adicionales en el archivo de directivas en tiempo de ejecución:
Serializadores no basados en reflexión. Los serializadores encontrados en la biblioteca de clases de .NET Framework, como las clases DataContractSerializer, DataContractJsonSerializer y XmlSerializer, no se basan en la reflexión. Sin embargo, requieren que el código se genere en función del objeto que se va a serializar o deserializar. Para obtener más información, vea la sección "serializadores Microsoft" en Serialization and Metadata.
Serializadores de terceros. Las bibliotecas de serialización de terceros, la más común de las cuales es el serializador JSON Newtonsoft, suelen basarse en la reflexión y requieren entradas en el archivo *.rd.xml para admitir la serialización y deserialización de objetos. Para obtener más información, consulte la sección "Serializadores de terceros" en Serialización y Metadatos.
Métodos que se basan en la reflexión
En algunos casos, el uso de la reflexión en el código no es obvio. Algunas API comunes o patrones de programación no se consideran parte de la API de reflexión, pero dependen de la reflexión para ejecutarse correctamente. Esto incluye los siguientes métodos de creación de instancias de tipo y método:
El método Type.MakeGenericType
Métodos Array.CreateInstance y Type.MakeArrayType
Método MethodInfo.MakeGenericMethod.
Para obtener más información, consulte APIs que se basan en la reflexión.
Nota:
Los nombres de tipo utilizados en los archivos de directivas en tiempo de ejecución deben estar completamente calificados. Por ejemplo, el archivo debe especificar "System.String" en lugar de "String".
Paso 3: Implementar y probar las compilaciones de versión de la aplicación
Después de actualizar el archivo de directivas del tiempo de ejecución, puede volver a compilar e implementar versiones de lanzamiento de la aplicación. Los archivos binarios de .NET Native se colocan en el subdirectorio ILC.out del directorio especificado en el cuadro de texto Build output path del cuadro de diálogo Properties del proyecto, pestaña Compile. Los archivos binarios que no están en esta carpeta no se han compilado con .NET Native. Pruebe exhaustivamente la aplicación y pruebe todos los escenarios, incluidos los escenarios de error, en cada una de sus plataformas de destino.
Si la aplicación no funciona correctamente (especialmente en los casos en los que produce MissingMetadataException o MissingInteropDataException excepciones en tiempo de ejecución), siga las instrucciones de la sección siguiente, Paso 4: Resolver manualmente los metadatos que faltan. La habilitación de excepciones de primera oportunidad puede ayudarle a encontrar estos errores.
Cuando haya probado y depurado las compilaciones de depuración de la aplicación y esté seguro de que ha eliminado la MissingMetadataException y la MissingInteropDataException, debe probar la aplicación como una aplicación .NET Native optimizada. Para ello, cambie la configuración del proyecto activo de Debug a Release.
Paso 4: Resolver manualmente los metadatos que faltan
El error más común que encontrará con .NET Native y que no encuentra en el escritorio es una excepción MissingMetadataException, MissingInteropDataException o MissingRuntimeArtifactException. En algunos casos, la ausencia de metadatos puede manifestarse en un comportamiento imprevisible o incluso en errores de aplicación. En esta sección se describe cómo puede depurar y resolver estas excepciones agregando directivas al archivo de directivas en tiempo de ejecución. Para obtener información sobre el formato de las directivas en tiempo de ejecución, vea Directivas en tiempo de ejecución (rd.xml) Referencia de archivo de configuración. Después de agregar directivas en tiempo de ejecución, debe implementar y probar su aplicación de nuevo y resolver cualquier MissingMetadataException, MissingInteropDataException, y MissingRuntimeArtifactException hasta que no encuentre más excepciones.
Sugerencia
Especifique las directivas en tiempo de ejecución en un nivel alto para permitir que la aplicación sea resistente a los cambios de código. Se recomienda agregar directivas de tiempo de ejecución a nivel de espacio de nombres y tipo en lugar de a nivel de miembro. Tenga en cuenta que puede haber un equilibrio entre resistencia y archivos binarios más grandes con tiempos de compilación más largos.
Al solucionar una excepción de metadatos que falta, tenga en cuenta estos problemas:
¿Qué era la aplicación que intentaba hacer antes de la excepción?
- Por ejemplo, ¿es el enlace de datos, la serialización o deserialización de datos, o directamente mediante la API de reflexión?
¿Se trata de un caso aislado o cree que encontrará el mismo problema para otros tipos?
- Por ejemplo, se produce una excepción MissingMetadataException al serializar un tipo en el modelo de objetos de la aplicación. Si conoce otros tipos que se serializarán, puede agregar directivas en tiempo de ejecución para esos tipos (o para sus espacios de nombres que contengan, dependiendo de la organización del código) al mismo tiempo.
¿Puede volver a escribir el código para que no use la reflexión?
Por ejemplo, ¿usa el código la palabra clave
dynamiccuando sabe qué tipo esperar?¿El código llama a un método que depende de la reflexión cuando hay disponible alguna alternativa mejor?
Nota:
Para obtener información adicional sobre el control de problemas que se derivan de diferencias en la reflexión y la disponibilidad de metadatos en aplicaciones de escritorio y .NET Nativo, consulte APIs That Rely on Reflection.
Para obtener algunos ejemplos específicos de control de excepciones y otros problemas que se producen al probar la aplicación, consulta:
Excepciones de tiempo de ejecución en aplicaciones nativas de .NET