Lanzamiento de Microsoft Windows App SDK 1.0 Stable, disponible para descargar (Notas de la versión)

Después de varias compilaciones de vista previa, Microsoft acaba de lanzar Windows App SDK 1.0.0 Stable, un conjunto de herramientas que permite a los desarrolladores de aplicaciones de escritorio crear aplicaciones con una interfaz de usuario, API y características de plataforma modernas de Windows.

En esta versión, Microsoft agregó varias funciones nuevas de Windows App SDK 0.8 y estabilizó los problemas de las versiones 1.0 Preview.

[lwptoc title=”WindowsAppSDK 1.0 Estable” width=”30%” float=”right”]

Interfaz de usuario de Windows 3

WinUI 3 es el marco de experiencia de usuario nativo (UX) para Windows App SDK.

Nuevas características y actualizaciones:

• Microsoft agregó nuevos controles (PipsPager, Expander, BreadcrumbBar) y actualizó los controles existentes para reflejar los últimos estilos de Windows de Interfaz de usuario de Windows 2.6.
• WinUI admite el empaquetado de MSIX de un solo proyecto mediante la creación de una nueva aplicación mediante la plantilla "Aplicación en blanco, empaquetada...".
• Microsoft ahora admite la implementación de aplicaciones WinUI 3 sin el paquete MSIX en las versiones de Windows 1809 y superiores. Por favor ver Cree una aplicación de escritorio sin empaquetar WinUI 3 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 podían establecerse en la versión 1903.
• La barra de herramientas en la aplicación, Hot Reload y Live Visual Tree para las aplicaciones empaquetadas de WinUI son compatibles con Visual Studio 2022 Preview 5 y GA.

Limitaciones importantes:

• Problemas conocidos de aplicaciones WinUI empaquetadas y no empaquetadas:
  • Error de tiempo de ejecución en aplicaciones de C++ que hacen referencia a un componente de tiempo de ejecución de Windows de C++: Para resolverlo, agregue el siguiente destino al final del .vcxproj del componente Windows Runtime:

    XMLCopiar

    <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 Aplicaciones WinUI con MSIX de proyecto único (Aplicación en blanco, plantilla empaquetada):
  • Falta el elemento de menú Empaquetar y publicar hasta que reinicie Visual Studio: Al crear una nueva aplicación con MSIX de proyecto único en Visual Studio 2019 y Visual Studio 2022 con la plantilla de proyecto de aplicación en blanco, empaquetada (WinUI 3 en escritorio), el comando para publicar el proyecto no aparece en el menú hasta que cierra y vuelva a abrir Visual Studio.
  • La aplicación AC# con MSIX de proyecto único no se compilará sin el componente opcional "C++ (v14x) Universal Windows Platform Tools" instalado. Vista Instalar herramientas de desarrollador para obtener información adicional.
  • Posible error en tiempo de ejecución en una aplicación con MSIX de proyecto único que consume tipos definidos en un componente de tiempo de ejecución de Windows al que se hace referencia: Para resolver, agregue manualmente entradas de clase activables a appxmanifest.xml.
    • El error esperado en las aplicaciones C# es “COMException: Clase no registrada (0x80040154 (REGDB_E_CLASSNOTREG)).
    • El error esperado en las aplicaciones C++/WinRT es “winrt::hresult_class_not_registered”.
• Problemas conocidos de Aplicaciones WinUI sin paquete MSIX (aplicaciones sin empaquetar):
  • Algunas API requieren la identidad del paquete y no se admiten en aplicaciones sin empaquetar, como:
    • Datos de la aplicación
    • StorageFile.GetFileFromApplicationUriAsync
    • StorageFile.CreateStreamedFileFromUriAsync
    • ApiInformación (no compatible con Windows 10)
    • Paquete.Actual
    • Cualquier API en el Windows.Modelo de aplicación.Recursos espacio de nombres
    • Cualquier API en el Microsoft.Windows.Modelo de aplicación.Recursos espacio de nombres
• Problemas conocidos de empaquetado e implementación de aplicaciones WinUI:
  • El  Package El comando no se admite en aplicaciones WinUI con MSIX de proyecto único (aplicación en blanco, plantilla empaquetada). En su lugar, utilice el Package & Publish Comando para crear un paquete MSIX.
  • Para crear un paquete NuGet a partir de una biblioteca de clases de C# con el Pack comando, asegúrese de que el activo Configuration is Release.
  • El  Pack El comando no es compatible con C++ Windows Runtime Components para crear un paquete NuGet.

Ventanas

El SDK de aplicaciones de Windows proporciona una ventana de aplicación que evoluciona la clase de vista previa fácil de usar Windows.UI.WindowManagement.AppWindow anterior y la pone a disposición de todas las aplicaciones de Windows, incluidas Win32, WPF y WinForms.

Nuevas características

• ventana de aplicación es una API de ventanas de alto nivel que permite escenarios de ventanas fáciles de usar que se integra 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 aloja su contenido y representa la entidad con la que los usuarios interactúan cuando cambian el tamaño y mueven su aplicación en la pantalla. Para los desarrolladores familiarizados con Win32, AppWindow puede verse como una abstracción de alto nivel de HWND.
• Área de visualización representa una abstracción de alto nivel de un HMONITOR, sigue los mismos principios que AppWindow.
• Monitor de área de visualización permite a un desarrollador observar los cambios en la topología de visualización y enumerar las áreas de visualización definidas actualmente en el sistema.

Entrada

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

Nuevas características

• API de puntero: PunteroPunto, Propiedades del punto de punteroy PointEventArgs para admitir la recuperación de información de eventos de puntero con API de entrada XAML.
• API InputPointerSource: representa un objeto que está registrado para informar la entrada del puntero y proporciona un control de eventos de entrada y cursor de puntero para la API SwapChainPanel de XAML.
• API de cursor: permite a los desarrolladores cambiar el mapa de bits del cursor.
• API de reconocimiento de gestos: permite a los desarrolladores reconocer determinados gestos, como arrastrar, mantener presionado y hacer clic cuando se les proporciona información del puntero.

Limitaciones importantes

• Todos PunteroPunto Se han eliminado las funciones estáticas de fábrica: ObtenerPuntoActual, ObtenerPuntoActualTransformado, ObtenerPuntosIntermediosy ObtenerPuntosIntermediosTransformados.
• El SDK de aplicaciones de Windows no admite la recuperación PunteroPunto objetos con identificadores de puntero. En su lugar, puede utilizar el PunteroPunto función miembro ObtenerPuntoTransformado para recuperar una versión transformada de una existente PunteroPunto objeto. Para puntos intermedios, puede utilizar el PointEventArgs funciones miembro ObtenerPuntosIntermedios y ObtenerPuntosIntermediosTransformados.
• Uso directo de la plataforma SDK API Operación Windows.UI.Core.CoreDrag no funcionará con aplicaciones WinUI.
• PunteroPunto propiedades Posición sin procesar y ContactoRectRaw se eliminaron porque se referían a valores no predichos, que eran los mismos que los valores normales en el sistema operativo. Usar Puesto de trabajo y ContactoRect en lugar de. La predicción del puntero ahora se maneja con el Microsoft.UI.Input.PointerPredictor objeto API.

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 incorporaron al SDK de aplicaciones de Windows para que las usen los tipos de aplicaciones de escritorio, especialmente las aplicaciones de consola sin empaquetar, las aplicaciones Win32, las aplicaciones de Windows Forms y las aplicaciones de WPF. La implementación del SDK de aplicaciones de Windows de estas funciones no se puede usar en aplicaciones para UWP, ya que existen funciones equivalentes en la propia plataforma para UWP.

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

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

Consideraciones importantes:

• Activación rica: GetActivatedEventArgs
  • Aplicaciones sin empaquetar: Totalmente utilizable.
  • aplicaciones empaquetadas: utilizable, pero estas aplicaciones también pueden usar la plataforma GetActivatedEventArgs. Tenga en cuenta que la plataforma define Windows.ApplicationModel.AppInstancia mientras que el SDK de aplicaciones de Windows define Microsoft.Windows.AppLifecycle.AppInstance. Y aunque las aplicaciones para UWP pueden usar el ActivatedEventArgs clases, como FileActivatedEventArgs y LaunchActivatedEventArgs, las aplicaciones que usan la función AppLifecycle del SDK de aplicaciones de Windows deben usar las interfaces, no las clases (p. ej., IFileActivatedEventArgs, ILaunchActivatedEventArgs, y así).
  • Aplicaciones WinUi: App.OnLaunched de WinUI recibe un Microsoft.UI.Xaml.LaunchActivatedEventArgs, mientras que la plataforma GetActivatedEventArgs devuelve un Windows.ApplicationModel.IActivatedEventArgsy el SDK de aplicaciones de Windows GetActivatedEventArgs devuelve un Microsoft.Windows.AppLifecycle.AppActivationArguments objeto que puede representar una plataforma LaunchActivatedEventArgs.
  • Para más información, consulte Activación enriquecida.
• Registrarse/Cancelar registro para activación enriquecida
  • Aplicaciones sin empaquetar: Totalmente utilizable.
  • aplicaciones empaquetadas: No se puede usar, use el manifiesto MSIX de la aplicación en su lugar.
  • Para más información, consulte Activación enriquecida.
• Instancia única/múltiple
  • Aplicaciones sin empaquetar: Totalmente utilizable.
  • aplicaciones empaquetadas: Totalmente utilizable.
  • Aplicaciones WinUI: si una aplicación desea 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 Main (C#) o WinMain (C++) donde puede hacer la detección y redirección.
  • RedirecciónActivaciónAAsync es una llamada asíncrona y no debe esperar una llamada asíncrona si su aplicación se ejecuta en una STA. Para las aplicaciones Windows Forms y C# WinUI, puede declarar que Main sea asíncrono, si es necesario. Para las aplicaciones C++ WinUI y C# WPF, no puede declarar Main como asíncrono, por lo que debe mover la llamada de redirección a otro subproceso para asegurarse de no bloquear la STA.
  • Para más información, consulte Creación de instancias de aplicaciones.
• Notificaciones de energía/estado
  • Aplicaciones sin empaquetar: Totalmente utilizable.
  • aplicaciones empaquetadas: Totalmente utilizable.
  • Para más información, consulte Gestión de energía.

Problema conocido:

• Las asociaciones de tipo de archivo codifican incorrectamente %1 para que sea %251 al configurar la plantilla de línea de comandos del controlador de verbos, lo que bloquea las aplicaciones Win32 sin empaquetar. Puede editar manualmente el valor del registro para que sea %1 como solución parcial. Si la ruta del archivo de destino tiene un espacio, seguirá fallando y no hay solución para ese escenario.
• Estos errores de instancias únicas/múltiples se solucionarán en un próximo parche de servicio:
  • La redirección de AppInstance no funciona cuando se compila para x86
  • Registrar una clave, anular el registro y volver a registrarla hace que la aplicación se bloquee

WriteCore

DWriteCore es la implementación del SDK de aplicaciones de Windows de DirectWrite, que es la API de DirectX para la representación de texto de alta calidad, fuentes de contorno independientes de la resolución y soporte completo de diseño y texto Unicode. 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 lo use en varias plataformas.

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

Limitaciones importantes

• DWriteCore no contiene las siguientes características de DirectWrite:
  • Fuentes por sesión
  • Fuentes de caracteres definidos por el usuario final (EUDC)
  • API de transmisión de fuentes
• La compatibilidad con la API de representación de bajo nivel es parcial.
• DWriteCore no interactúa con Direct2D, pero puede usar IDWriteGlyphRunAnálisis y IDWriteBitmapRenderTarget.

Núcleo de MRT

MRT Core es una versión optimizada del moderno Windows Sistema de gestión de recursos que se distribuye como parte del SDK de aplicaciones de Windows.

Limitaciones importantes

• En los proyectos .NET, los archivos de recursos copiados y pegados en la carpeta del proyecto no se indexan en F5 si la aplicación ya se creó. Como solución alternativa, reconstruya la aplicación. Ver problema 1503 para más información.
• En los proyectos .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 indexen de manera predeterminada. Ver problema 1786 para más información. Para solucionar este problema, elimine las siguientes entradas del archivo CSPROJ:

  XMLCopiar

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

• Para las aplicaciones WinUI de C++ sin empaquetar, el URI del recurso no está construido correctamente. Para solucionar este problema, agregue lo siguiente en vcxproj:

  XMLCopiar

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

Despliegue

Nuevas funciones y actualizaciones

• Puede inicializar automáticamente el SDK de aplicaciones de Windows a través de WindowsPackageType project propiedad para cargar el tiempo de ejecución del SDK de aplicaciones de Windows y llamar a las API del SDK de aplicaciones de Windows. Ver Crear una aplicación WinUI 3 para obtener instrucciones.
• Las aplicaciones sin empaquetar pueden implementar el SDK de aplicaciones de Windows integrándose en el SDK de aplicaciones de Windows independiente. .exe instalador en su MSI existente o programa de instalación. Para obtener más información, consulte Guía de implementación del SDK de aplicaciones de Windows para aplicaciones no empaquetadas.
• Las aplicaciones .NET sin empaquetar también pueden usar el envoltorio .NET para el API de arranque para tomar dinámicamente una dependencia en el paquete de marco SDK de aplicaciones de Windows en tiempo de ejecución. Para obtener más información sobre el contenedor .NET, consulte Biblioteca contenedora .NET.
• Las aplicaciones empaquetadas pueden usar la API de implementación para verificar y garantizar 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 .NET para la API de arranque solo está diseñado para que lo usen aplicaciones .NET sin empaquetar para simplificar el acceso al SDK de aplicaciones de Windows.
• Solo las aplicaciones empaquetadas de MSIX que son de plena confianza o tienen la gestión de paquetes la capacidad restringida tiene permiso para usar la API de implementación para instalar las dependencias del paquete principal y único. El soporte para aplicaciones empaquetadas de confianza parcial vendrá en versiones posteriores.
• Cuando F5 prueba una aplicación x86 que usa el DeploymentManager.Inicializar método en un sistema x64, asegúrese de que el marco x64 se instala primero ejecutando el WindowsAppRuntimeInstall.exe. De lo contrario, se encontrará con un EXTRAVIADO error debido a que Visual Studio no implementó el marco x64, lo que normalmente ocurre a través de la implementación de la tienda o la instalación de prueba.

Otras limitaciones y problemas conocidos

• No hay soporte para cualquier configuración de compilación de CPU: Cuando agregando el SDK de aplicaciones de Windows a una aplicación o componente .NET existente que admita Cualquier CPU, debe especificar la arquitectura deseada: x86, x64 or arm64.
• Actualización de .NET 5 a .NET 6: Al actualizar en la interfaz de usuario de Visual Studio, es posible que encuentre errores de compilación. Como solución alternativa, actualice manualmente el TargetFrameworkPackage de su archivo de proyecto a lo siguiente:

  XMLCopiar

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

• La aplicación MSIX de proyecto único de C# no se compila si las herramientas para UWP de C++ no están instaladas. Si tiene un proyecto MSIX de proyecto único de C#, deberá instalar el Herramientas de plataforma universal de Windows C++ (v14x) componente opcional.
• El idioma posterior VSIX no se instala en Visual Studio 2019 cuando se instalan varias versiones de Visual Studio 2019. Si tiene varias versiones de Visual Studio 2019 instaladas (por ejemplo, Release y Preview) y luego instale Windows App SDK VSIX para ambos C++ y C#, la segunda instalación fallará. Para resolverlo, desinstale las herramientas de empaquetado MSIX de proyecto único para Visual Studio 2019 después del primer idioma VSIX. Vista esta retroalimentación para obtener información adicional sobre este problema.
• Si deseas co_await en  DispatcherQueue.TryEnqueue método, luego use el currículum_primer plano función auxiliar en el Biblioteca de implementación de Windows (WIL):
  1. Agregar una referencia a Microsoft.Windows.ImplementationLibrary Paquete NuGet.
  2. Agregue la #include <wil/cppwinrt_helpers.h> declaración a su archivo de código.
  3. Uso wil::resume_foreground(your_dispatcher); a co_await el resultado.

Lea más y encuentre los enlaces de descarga en Microsoft esta página.