Notas de la versión del canal estable para el SDK Windows App

El canal estable proporciona versiones del SDK de Windows que son compatibles con el uso de aplicaciones en entornos de producción. Las aplicaciones que usan la versión estable del SDK Windows app también se pueden publicar en el Microsoft Store.

Las siguientes versiones del canal estable están disponibles actualmente:

• Versión 1.0
• Versión 0.8
• Versión 0.5

Si desea actualizar una aplicación existente de una versión anterior del SDK de aplicaciones de Windows a una versión más reciente, consulte Actualización de proyectos existentes a la versión más reciente del SDK de Windows App.

Versión 1.0

La versión 1.0 es la versión más reciente del canal estable para el SDK Windows App. 1.0 admite todas las características de canal estables.

Descargas para 1.0 Estable

En la tabla siguiente puede descargar las extensiones Visual Studio (VSIX) y el instalador .exe para la versión estable 1.0. Si aún no lo ha hecho, instale las herramientas de desarrollo.

En las secciones siguientes se describen las características nuevas y actualizadas, las limitaciones y los problemas conocidos de 1.0 Stable.

WinUI 3

WinUI 3 es el marco de experiencia del usuario nativo (UX) para Windows APP SDK. En esta versión hemos agregado varias características nuevas de Windows App SDK 0.8 y problemas estabilizados de las versiones preliminares 1.0.

Nuevas características y actualizaciones:

• Hemos agregado nuevos controles (PipsPager, Expander, BreadcrumbBar) y hemos actualizado los controles existentes para reflejar los estilos de Windows más recientes de WinUI 2.6.
• El empaquetado MSIX de un solo proyecto se admite en WinUI mediante la creación de una nueva aplicación con la "Aplicación en blanco, empaquetada...". Segmentación.
• Ahora se admite la implementación de aplicaciones WinUI 3 sin empaquetado MSIX en Windows versiones 1809 y posteriores. Consulte Creación de una aplicación de escritorio WinUI 3 sin empaquetar para obtener información adicional.
• Los proyectos de WinUI 3 ahora pueden establecer su versión de destino en Windows 10, versión 1809. Anteriormente, solo se podían establecer tan bajo como la versión 1903.
• La barra de herramientas en la Recarga activa, el árbol visual en directo para aplicaciones empaquetadas winUI se admiten en Visual Studio versión preliminar 5 de & 2022 y en la versión preliminar 5 de WinUI.

Limitaciones importantes:

• Problemas conocidos de las aplicaciones WinUI empaquetadasy no empaquetadas:

  • Error en tiempo de ejecución en las aplicaciones de C++ que hacen referencia a un componente en tiempo de ejecución de Windows de C++: para resolverlo, agregue el destino siguiente al final del archivo .vcxproj del componente en tiempo de ejecución de Windows:

    <Target Name="GetPriIndexName">
    <PropertyGroup>
        <!-- Winmd library targets use the default root namespace of the project for the App package name -->
        <PriIndexName Condition="'$(RootNamespace)' != ''">$(RootNamespace)</PriIndexName>
        <!-- If RootNamespace is empty fall back to TargetName -->
        <PriIndexName Condition="$(PriIndexName) == ''">$(TargetName)</PriIndexName>
    </PropertyGroup>
    </Target>
    

• Problemas conocidos de las aplicaciones WinUI con MSIX de un solo proyecto (aplicación vacía, plantilla empaquetada):

  • Falta el paquete Publicar elemento de menú hasta reiniciar Visual Studio: al crear una nueva aplicación con MSIX de un solo proyecto en Visual Studio 2019 y Visual Studio 2022 mediante la plantilla de proyecto Aplicación vacía empaquetada (WinUI 3 en escritorio), el comando para publicar el proyecto no aparecerá en el menú hasta que cierre y vuelva a abrir Visual Studio .
  • Una aplicación de C# con MSIX de un solo proyecto no se compilará sin el componente opcional "C++ (v14x) Universal Windows Platform Tools" instalado. Consulte Instalación de herramientas para desarrolladores para obtener información adicional.
  • Posible error en tiempo de ejecución en una aplicación con MSIX de un solo proyecto que consume tipos definidos en un componente en tiempo de ejecución de Windows al que se hace referencia: para resolverlo, agregue manualmente entradas de clase activables a la appxmanifest.xml.
    • El error esperado en las aplicaciones de C# es "COMException: clase no registrada (0x80040154 (REGDB_E_CLASSNOTREG)).
    • El error esperado en las aplicaciones de C++/WinRT es "winrt::hresult_class_not_registered".

• Problemas conocidos de las aplicaciones WinUI sin empaquetado MSIX (aplicaciones sin empaquetar):

  • Algunas API requieren la identidad del paquete y no se admiten en aplicaciones sin empaquetar, como:
    • ApplicationData
    • StorageFile.GetFileFromApplicationUriAsync
    • StorageFile.CreateStreamedFileFromUriAsync
    • ApiInformation (no se admite en Windows 10)
    • Package.Current
    • Cualquier API del Windows. Espacio de nombres ApplicationModel.Resources
    • Cualquier API en Microsoft.Windows. Espacio de nombres ApplicationModel.Resources

• Problemas conocidos para empaquetar e implementar aplicaciones WinUI:

  • El comando no se admite en aplicaciones WinUI con MSIX de un solo proyecto Package (aplicación vacía, plantilla empaquetada). En su lugar, Package & Publish use el comando para crear un paquete MSIX.
  • Para crear un NuGet desde una biblioteca de clases de C# con el Pack comando , asegúrese de que el activo es ConfigurationRelease .
  • El Pack comando no se admite en C++ Windows Runtime Components para crear un NuGet paquete.

Para más información o para empezar a desarrollar con WinUI, consulte:

• Windows ui 3 (WinUI)
• Introducción al desarrollo de aplicaciones con WinUI 3

Basado en ventanas

El SDK Windows App proporciona una clase AppWindow que evoluciona las versiones anteriores fáciles de Windows. UI. Clase de versión preliminar WindowManagement.AppWindow y hace que esté disponible para todas Windows aplicaciones, incluidos Win32, WPF y WinForms.

Nuevas características

• AppWindow es una API de ventana de alto nivel que permite escenarios de ventanas fáciles de usar que se integran bien con la experiencia del usuario de Windows y con otras aplicaciones. Representa una abstracción de alto nivel de un contenedor administrado por el sistema del contenido de una aplicación. Este es el contenedor en el que se hospeda el contenido y representa la entidad con la que interactúan los usuarios al cambiar el tamaño y mover la aplicación en pantalla. Para los desarrolladores familiarizados con Win32, AppWindow se puede ver como una abstracción de alto nivel del HWND.
• DisplayArea representa una abstracción de alto nivel de un HMONITOR, sigue los mismos principios que AppWindow.
• DisplayAreaWatcher permite a los desarrolladores observar los cambios en la topología de visualización y enumerar DisplayAreas definidos actualmente en el sistema.

Para más información, consulte Administración de ventanas de aplicaciones.

Entrada

Estas son las API de entrada que admiten WinUI y proporcionan una superficie de API de nivel inferior para que los desarrolladores puedan lograr interacciones de entrada más avanzadas.

Nuevas características

• API de puntero: PointerPoint, PointerPointPropertiesy PointerEventArgs para admitir la recuperación de información de eventos de puntero con las API de entrada XAML.
• API InputPointerSource:representa un objeto registrado para informar de la entrada de puntero y proporciona control de eventos de entrada y cursor de puntero para la API SwapChainPanel de XAML.
• CURSOR API:permite a los desarrolladores cambiar el mapa de bits del cursor.
• GestureRecognizer API:permite a los desarrolladores reconocer determinados gestos, como arrastrar, mantener presionado y hacer clic cuando se proporciona información de puntero.

Limitaciones importantes

• Se han quitado todas las funciones de generador estático de PointerPoint:GetCurrentPoint, GetCurrentPointTransformed,GetIntermediatePointsy GetIntermediatePointsTransformed.
• El WINDOWS App SDK no admite la recuperación de objetos PointerPoint con los IDs de puntero. En su lugar, puede usar la función miembro PointerPointGetTransformedPoint para recuperar una versión transformada de un objeto PointerPoint existente. Para los puntos intermedios, puede usar las funciones miembro PointerEventArgsGetIntermediatePoints y GetTransformedIntermediatePoints.
• Uso directo de la API del SDK de Windows. UI. Core.CoreDragOperation no funcionará con aplicaciones WinUI.
• Las propiedades RawPosition y ContactRectRaw de PointerPoint se quitaron porque hacían referencia a valores no predichos, que eran los mismos que los valores normales del sistema operativo. En su lugar, use Position y ContactRect. La predicción de puntero ahora se controla con el objeto de API Microsoft.UI.Input.PointerPredictor.

Ciclo de vida de la aplicación

La mayoría de las características del ciclo de vida de la aplicación ya existen en la plataforma UWP y se han incluido en el SDK de aplicaciones de Windows para su uso por tipos de aplicaciones de escritorio, especialmente aplicaciones de consola sin empaquetar, aplicaciones Win32, aplicaciones de Windows Forms y aplicaciones WPF. La Windows SDK de aplicaciones de estas características no se puede usar en aplicaciones para UWP, ya que hay características equivalentes en la propia plataforma UWP.

Las aplicaciones que no son de UWP también se pueden empaquetar en paquetes MSIX. Aunque estas aplicaciones pueden usar algunas de las características Windows ciclo de vida de la aplicación del SDK de aplicaciones, deben usar el enfoque de manifiesto cuando esté disponible. Por ejemplo, no pueden usar las API registerForXXXActivation del SDK de Windows y, en su lugar, deben registrarse para la activación enriquecte a través del manifiesto.

Todas las restricciones de las aplicaciones empaquetadas también se aplican a las aplicaciones WinUI, que están empaquetadas, y hay consideraciones adicionales, como se describe a continuación.

Consideraciones importantes:

• Activación enriquecte: GetActivatedEventArgs

  • Aplicaciones sin empaquetar:totalmente utilizables.
  • Aplicaciones empaquetadas:se pueden usar, pero estas aplicaciones también pueden usar la plataforma . Tenga en cuenta que la plataforma define Windows. ApplicationModel.AppInstance, mientras que el SDK Windows app define Microsoft.Windows. AppLifecycle.AppInstance. Y aunque las aplicaciones para UWP pueden usar las clases , como y , las aplicaciones que usan la característica AppLifecycle del SDK de aplicaciones de Windows deben usar las interfaces no las clases (por ejemplo, , , , y ActivatedEventArgsFileActivatedEventArgs así LaunchActivatedEventArgsIFileActivatedEventArgsILaunchActivatedEventArgs sucesivamente).
  • Aplicaciones WinUi:App.OnLaunched de WinUI tiene un objeto Microsoft.UI.Xaml.LaunchActivatedEventArgs,mientras que la plataforma devuelve un Windows. ApplicationModel.IActivatedEventArgsy WindowsAppSDK devuelven microsoft.Windows. Objeto AppLifecycle.AppActivationArguments que puede representar una plataforma .
  • Para obtener más información, vea Activación enriquecte.

• Registro o anulación del registro para la activación enriquección

  • Aplicaciones sin empaquetar:totalmente utilizables.
  • Aplicaciones empaquetadas:no se puede usar el manifiesto MSIX de la aplicación en su lugar.
  • Para obtener más información, vea Activación enriquecte.

• Creación de instancias únicas o múltiples

  • Aplicaciones sin empaquetar:totalmente utilizables.
  • Aplicaciones empaquetadas:totalmente utilizables.
  • Aplicaciones WinUI:si una aplicación quiere detectar otras instancias y redirigir una activación, debe hacerlo lo antes posible y antes de inicializar cualquier ventana, etc. Para habilitar esto, la aplicación debe definir DISABLE_XAML_GENERATED_MAIN y escribir un elemento Main (C#) o WinMain (C++) personalizado, donde puede realizar la detección y el redireccionamiento.
  • RedirectActivationToAsync es una llamada asincrónica y no debe esperar una llamada asincrónica si la aplicación se ejecuta en un STA. Para Windows forms y aplicaciones WinUI de C#, puedes declarar Main como asincrónico, si es necesario. En el caso de las aplicaciones de C++ WinUI y WPF de C#, no puede declarar Main como asincrónico, por lo que en su lugar debe mover la llamada de redireccionamiento a otro subproceso para asegurarse de que no bloquea el STA.
  • Para más información, consulte Creación de instancias de aplicaciones.

• Notificaciones de energía y estado

  • Aplicaciones sin empaquetar:totalmente utilizables.
  • Aplicaciones empaquetadas:totalmente utilizables.
  • Para más información, consulte Administración de energía.

Problema conocido:

• Las asociaciones de tipo de archivo codifican incorrectamente %1 para que sea %251 al establecer la plantilla de línea de comandos del controlador de verbos, que bloquea las aplicaciones Win32 sin empaquetar. Puede editar manualmente el valor del Registro para que sea %1 en su lugar como una solución alternativa parcial. Si la ruta de acceso del archivo de destino tiene un espacio, se producirá un error y no hay ninguna solución alternativa para ese escenario.
• Estos errores de creación de instancias únicas o múltiples se corregirán en una próxima revisión de mantenimiento:
  • El redireccionamiento de AppInstance no funciona cuando se compila para x86
  • Registrar una clave, anular su registro y volver a registrarla hace que la aplicación se bloquea.

DWriteCore

DWriteCore es la implementación del SDK de Windows App de DirectWrite,que es la API de DirectX para la representación de texto de alta calidad, fuentes de esquema independientes de la resolución y compatibilidad completa con texto Unicode y diseño. DWriteCore es una forma de DirectWrite que se ejecuta en versiones de Windows hasta Windows 10, versión 1809 (10.0; Compilación 17763) y abre la puerta para que la use multiplataforma.

Funciones DWriteCore contiene todas las características de DirectWrite, con algunas excepciones.

Limitaciones importantes

• DWriteCore no contiene las siguientes DirectWrite características:
  • Fuentes por sesión
  • Fuentes de caracteres definidos por el usuario final (EUDC)
  • API de streaming de fuentes
• La compatibilidad con la API de representación de bajo nivel es parcial.
• DWriteCore no interopera con Direct2D, pero puede usar IDWriteGlyphRunAnalysis e IDWriteBitmapRenderTarget.

Para obtener más información, vea Introducción a DWriteCore.

MRT Core

MRT Core es una versión simplificada del sistema de administración de recursos Windows moderno que se distribuye como parte del SDK Windows App.

Limitaciones importantes

• En los proyectos de .NET, los archivos de recursos copiados en la carpeta del proyecto no se indexa en F5 si la aplicación ya se ha creado. Como solución alternativa, recompile la aplicación. Consulte el problema 1503 para obtener más información.
• En los proyectos de .NET, cuando se agrega un archivo de recursos al proyecto mediante la interfaz de usuario de Visual Studio, es posible que los archivos no se indexe de forma predeterminada. Consulte el problema 1786 para obtener más información. Para evitar este problema, quite las entradas siguientes en el archivo CSPROJ:

  <ItemGroup>
      <Content Remove="<image file name>" />
  </ItemGroup>
  <ItemGroup>
      <PRIResource Remove="<resw file name>" />
  </ItemGroup>
  

• En el caso de las aplicaciones WinUI de C++ sin empaquetar, el URI del recurso no se ha creado correctamente. Para evitar este problema, agregue lo siguiente en vcxproj:

  <!-- Add the following after <Import Project="$(VCTargetsPath)\Microsoft.Cpp.props" /> -->
  
  <PropertyGroup>
      <AppxPriInitialPath></AppxPriInitialPath>   
  </PropertyGroup>
  

Para más información, consulte Administración de recursos con MRT Core.

Implementación

Nuevas características y actualizaciones

• Puede inicializar automáticamente el SDK de Windows App mediante la propiedad para cargar el entorno de ejecución del SDK de Windows App y llamar a las API Windows WindowsPackageType project APP SDK. Consulte Creación de una aplicación WinUI 3 para obtener instrucciones.
• Las aplicaciones sin empaquetar pueden implementar Windows SDK de aplicaciones mediante la integración en el instalador independiente de Windows App SDK en el msi o programa .exe de instalación existente. Para más información, consulte la guía Windows implementación del SDK de aplicaciones para aplicaciones sin empaquetar.
• Las aplicaciones .NET sin empaquetar también pueden usar el contenedor de .NET para que la API de programa previo tome dinámicamente una dependencia en el paquete del marco del SDK de Windows App en tiempo de ejecución. Para obtener más información sobre el contenedor de .NET, vea Biblioteca de contenedores de .NET.
• Las aplicaciones empaquetadas pueden usar la API de implementación para comprobar y asegurarse de que todos los paquetes necesarios están instalados en la máquina. Para obtener más información sobre cómo funciona la API de implementación, consulte la guía de implementación para aplicaciones empaquetadas.

Limitaciones importantes

• El contenedor de .NET para la API de programa previo solo está pensado para que lo usen las aplicaciones .NET sin empaquetar para simplificar el acceso al SDK de Windows App.
• Solo las aplicaciones empaquetadas msiX que son de plena confianza o tienen la funcionalidad restringida packageManagement tienen el permiso para usar la API de implementación para instalar las dependencias de paquete principal y singleton. La compatibilidad con aplicaciones empaquetadas de confianza parcial estará disponible en versiones posteriores.
• Cuando F5 prueba una aplicación x86 que usa el método DeploymentManager.Initialize en un sistema x64, asegúrese de que el marco x64 se instala por primera vez mediante la ejecución del WindowsAppRuntimeInstall.exe. De lo contrario, se producirá un error NOT_FOUND debido a que Visual Studio no implementa el marco x64, lo que normalmente se produce a través de la implementación del almacén o la instalación de instalación local.

Otras limitaciones y problemas conocidos

• No se admite ningunaconfiguración de compilación de CPU: al agregar el SDK de aplicación de Windows a una aplicación o componente de .NET existente que admita Cualquier CPU,debe especificar la arquitectura deseada: o .

• Actualización de .NET 5 a .NET 6:al actualizar en la interfaz de usuario de Visual Studio, puede encontrar errores de compilación. Como solución alternativa, actualice manualmente targetFrameworkPackage del archivo de proyecto a lo siguiente:

      <TargetFramework>net6.0-windows10.0.19041.0</TargetFramework> 
  

• La aplicación MSIX de un solo proyecto de C# no se compila si las herramientas de C++ para UWP no están instaladas. Si tiene un proyecto MSIX de un solo proyecto de C#, deberá instalar el componente opcional Herramientas de plataforma universal de C++ (v14 Windows x).

• El lenguaje VSIX posterior no se puede instalar en Visual Studio 2019 cuando se instalan varias versiones de Visual Studio 2019. Si tiene varias versiones de Visual Studio 2019 instaladas (por ejemplo, versión preliminar) y, a continuación, instala el VSIX del SDK de aplicación de Windows para C++ y C#, se producirá un error en la segunda instalación. Para resolverlo, desinstale las herramientas de empaquetado MSIX de un solo proyecto Visual Studio 2019 después del primer vsix de lenguaje. Consulte estos comentarios para obtener información adicional sobre este problema.

• Si desea usar el método co_awaitco_await use la función auxiliar resume_foreground en la biblioteca de implementación de Windows (WIL):

  1. Agregue una referencia a Microsoft.Windows. ImplementationLibrary NuGet paquete.
  2. Agregue la #include <wil/cppwinrt_helpers.h> instrucción al archivo de código.
  3. Use wil::resume_foreground(your_dispatcher); para co_await el resultado.

Versión 0.8

La versión más reciente disponible del canal estable es la versión de mantenimiento 0.8.5.

Versión 0.8.5

Se trata de una versión de mantenimiento del SDK de Windows App que incluye correcciones de errores más críticas para la versión 0.8.0.

Corrección de errores

• Se ha corregido un problema que provocaba que se bloqueara la entrada de puntero de las aplicaciones WinUI.
• Se ha corregido un problema que provocaba que los botones de la barra de título (min, max, close) no tengan esquinas redondeadas Windows 11.
• Se ha corregido un problema que provocaba que las opciones de diseño de cambiar el tamaño no aparezcan al mantener el puntero sobre el botón maximizar o restaurar Windows 11.
• Se ha corregido un problema que provocaba una excepción de bloqueo en la que se creaba un objeto PointCollection. Para más información, consulte el problema 971 en GitHub.

Las limitaciones y los problemas conocidos de la versión 0.8 también se aplican a la versión 0.8.5, a menos que se marque lo contrario en la sección siguiente.

Versión 0.8.4

Se trata de una versión de mantenimiento del SDK de Windows App que incluye correcciones de errores más críticas para la versión 0.8.0.

Corrección de errores

• Correcciones de las barras de título personalizadas para que ContentDialog no lo cubra y los botones de la barra de título se redondee.
• Corrección de un bloqueo en el procesamiento de imágenes cuando se cambia la escala de pantalla.
• Corrige errores de recorte en los que la interfaz de usuario desaparece o se recorta incorrectamente

Las limitaciones y los problemas conocidos de la versión 0.8 también se aplican a la versión 0.8.4, a menos que se marque lo contrario en la sección siguiente.

Versión 0.8.3

Se trata de una versión de mantenimiento del SDK de Windows App que incluye correcciones de errores más críticas para la versión 0.8.0.

Corrección de errores

El foco del teclado se pierde cuando se minimiza una ventana y, a continuación, se restaura, lo que requiere un clic del mouse para restaurar el foco.

Las limitaciones y los problemas conocidos de la versión 0.8 también se aplican a la versión 0.8.3, a menos que se marque lo contrario en la sección siguiente.

Versión 0.8.2

Se trata de una versión de mantenimiento del SDK de Windows App que incluye correcciones de errores más críticas para la versión 0.8.0.

Corrección de errores

• Windows SDK de aplicaciones y WinUI 3 ahora se admiten en Visual Studio 2022 Preview 2 y versiones posteriores.
• En el caso de las aplicaciones .NET, puede recibir el siguiente error al pasar una matriz de enumeraciones: Object contains non-primitive or non-blittable data.
• La escritura con el Panel de escritura a mano dentro de un cuadro de texto provoca un bloqueo
• Los iconos o imágenes siempre se cargan en su valor de escala al 100 % en lugar de en función del valor de escala del monitor.
• La recolección de elementos no utilizados de EventSource > T provoca un error posterior al cancelar la suscripción de controladores > para obtener más detalles).
• Corrección de seguridad: consulte CVE-2021-34533 para obtener más detalles.
• SwapChainPanel.CompositionScaleChanged devuelve a veces valores incorrectos de CompositionScale después de cambiar la escala de presentación

Las limitaciones y los problemas conocidos de la versión 0.8 también se aplican a la versión 0.8.2, a menos que se marque lo contrario en la sección siguiente.

Versión 0.8.1

Se trata de una versión de mantenimiento del SDK de Windows App que incluye algunas correcciones de errores críticos para la versión 0.8.0.

Corrección de errores

• Windows SDK de aplicación no se puede ejecutar en la compilación Windows Insider más reciente
• Bloqueo en EditableComboBox al escribir un valor que no aparece en la lista desplegable
• WebView2 no permite al usuario salir con tabulación una vez que se ha recibido el foco.
• Requisitos completos Windows. Espacio de nombres Foundation.Metadata.DefaultOverload en código generado por WinUI para evitar la ambigüedad del espacio de nombres
  • Esto corrige el error 5108.
• Corrección de seguridad: consulte CVE-2021-34489 para obtener más detalles.

Las limitaciones y los problemas conocidos de la versión 0.8 también se aplican a la versión 0.8.1, a menos que se marque lo contrario en la sección siguiente.

Versión 0.8.0 estable

Nuevas características y actualizaciones

Esta versión admite todas las características de canal estables.

WinUI 3

Esta versión incluye muchas correcciones de errores y una estabilización mejorada en WinUI 3. Estos son todos los cambios nuevos en WinUI 3 desde el lanzamiento de WinUI 3 - Project La 0.5:

• El control Pivot se ha vuelto a agregar y ahora se puede usar en cualquier aplicación WinUI 3.

• En esta versión se incluyen todas las correcciones de errores de Project Loaa v0.5.5, v0.5.6 y v0.5.7.

• Nuevas correcciones de errores, entre las que se incluyen:

  • El clic con el botón derecho del mouse en TextBox bloquea la aplicación
  • El elemento NavigationView provoca un bloqueo en UWP, Reunion 0.5 versión preliminar
  • El elemento ProgressBar no muestra la diferencia entre las opciones En pausa y Error
  • Bloqueo en RichEditBox al copiar, pegar o cambiar el estilo de texto
  • Los botones de título de ventana están mal ubicados cuando SetTitleBar no está establecido o es NULL.

  Para obtener la lista completa de errores solucionados en esta versión, consulte nuestro repositorio GitHub .

• La ColorHelper.ToDisplayName API ya no está disponible.

• Se han quitado los siguientes tipos:

  • Microsoft.Graphics.IGeometrySource2D
  • Microsoft.Graphics.IGeometrySource2DInterop

  Utilice Windows.Graphics.IGeometrySource2D y Windows.Graphics.IGeometrySource2DInterop en su lugar.

• Todos los tipos del espacio de nombres se han movido al espacio de nombres Microsoft.System , incluida la clase Microsoft.UI.DispatchingMicrosoft.System.

• La AcrylicBrush.BackgroundSource propiedad se ha quitado, ya que no se admite como en HostBackdropBackgroundSource WinUI 3.

Para obtener más información sobre WinUI, consulte Windows ui 3 Library (WinUI) (Biblioteca de IU 3 [WinUI]).

Para ver los controles y características de WinUI 3 en acción, puede clonar y compilar la aplicación WinUI 3 Controls Gallery desde GitHubo descargar la aplicación desde el Microsoft Store .

Para empezar a desarrollar con WinUI, consulte los siguientes artículos:

• Plantillas de proyecto de WinUI 3 en Visual Studio
• Introducción al desarrollo de aplicaciones con WinUI 3
• Aplicaciones de escritorio WinUI 3 e interoperabilidad básica de Win32
• Referencia de API de WinUI 3

DWriteCore

Esta versión de DWriteCore incluye las siguientes características nuevas y actualizadas. DWriteCore se presenta y se describe en la introducción a DWriteCore.

• DWriteCore ahora es compatible con el subrayado; vea IDWriteTextLayout::GetUnderline e IDWriteTextLayout::SetUnderline.
• Compatibilidad con el tachado: vea IDWriteTextLayout::GetStrikethrough e IDWriteTextLayout::SetStrikethrough.
• Compatibilidad con texto vertical a través de IDWriteTextLayout(vea Texto vertical).
• Se implementan todos los métodos de las interfaces IDWriteTextAnalyzer e IDWriteTextAnalyzer1.
• La función gratuita DWriteCoreCreateFactory crea un objeto de generador que se usa para la posterior creación de objetos DWriteCore individuales.

Para obtener información sobre DWriteCore DirectWrite referencia de API, consulte Referencia de API de DWriteCore y referencia DirectWrite API de DWriteCore.

MRTCore

• La acción de compilación para recursos se establece automáticamente al agregar el recurso al proyecto, lo que reduce la necesidad de configuración manual del proyecto.

Limitaciones

• Esta versión no se admite actualmente en el canal de desarrollo de la Windows Programa Insider. Esto se ha corregido en la versión 0.8.1.

• Aplicaciones de escritorio (escritorio de C#o C++): esta versión solo se admite para su uso en aplicaciones de escritorio (C++ o C#) que se empaquetan mediante MSIX. Para usar el SDK Windows app en aplicaciones de escritorio no empaquetadas, debe usar el canal de versión experimental.

Problemas conocidos

• Las herramientas de WinUI 3, como Live Visual Tree, Live Property Explorer y Recarga activa en la versión 0.8 y posteriores, requieren Visual Studio 2019 16.11 Preview 3 y versiones posteriores.

• Las aplicaciones que actualmente usan WinUI 3 y Windows App SDK 0.8 no pueden usar bibliotecas de clases que usan Project La 0.5. Actualice las bibliotecas de clases para usar Windows App SDK 0.8.

• Las aplicaciones .NET deben tener como destino la compilación 18362 o superior: el TFM debe establecerse en net5.0-windows10.0.18362 o superior, y el del proyecto de empaquetado debe establecerse en 18362 o superior. Para obtener más información, vea GitHub problema #921.

• Es posible que se encuentre un bloqueo al cambiar con frecuencia entre el modo claro y el oscuro.

• En el caso de las aplicaciones .NET, puede recibir el siguiente error al pasar una matriz de enumeraciones: Esto se ha corregido en la Object contains non-primitive or non-blittable data.Object contains non-primitive or non-blittable data.

• En el caso de las aplicaciones .NET, actualmente no hay ninguna manera de rechazar la indexación de una imagen como un recurso de aplicación mediante la interfaz Visual Studio usuario. Para evitar este problema, agregue un archivo Directory.Build.targets (consulte Personalización de la compilación - Visual Studio para obtener instrucciones) al proyecto y quite las imágenes como se muestra a continuación:

  • Para quitar imágenes específicas (tenga en cuenta que se necesita la ruta de acceso relativa):

    <Project> 
    <ItemGroup> 
        <Content Remove="..\Bitmap1.bmp" />
    </ItemGroup>
    </Project>
    

  • Para quitar imágenes basadas en metadatos:

    <Project>
    <ItemGroup>
        <Content Remove="@(None->WithMetadataValue('Pack','true'))" />
    </ItemGroup>
    </Project>
    

  Se planea una corrección para este problema para una próxima versión: en ese momento, ya no se necesitan las soluciones alternativas anteriores.

Versión 0.5

La versión de mantenimiento más reciente disponible es 0.5.9.

Nuevas características y actualizaciones

Esta versión admite todas las características de canal estables.

Limitaciones y problemas conocidos

Esta versión tiene las siguientes limitaciones y problemas conocidos:

• Aplicaciones de escritorio (escritoriode C# o C++): esta versión solo se admite para su uso en aplicaciones de escritorio (C++ o C#) que se empaquetan mediante MSIX. Para usar el SDK Windows app en aplicaciones de escritorio no empaquetadas, debe usar el canal de versión experimental.
• Las aplicaciones .NET deben tener como destino la compilación 18362o superior: el TFM debe establecerse en o superior, y el de su proyecto de empaquetado debe establecerse en <TargetPlatformVersion> 18362 o superior. Para obtener más información, vea el problema conocido en GitHub.

Temas relacionados

• Canal de versión preliminar
• Canal experimental
• Configuración del entorno de desarrollo
• Creación de un nuevo proyecto que use el SDK de Aplicaciones para Windows
• Uso del SDK de Aplicaciones para Windows en un proyecto existente
• Implementación de aplicaciones que usan Windows App SDK