Compartir a través de

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

  • Artículo

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

Vínculos importantes:

Versión del canal estable más reciente:

Descargas para el SDK de Aplicaciones para Windows

Nota:

Las extensiones de Visual Studio (VSIX) del SDK de Aplicaciones para Windows ya no se distribuyen como descarga independiente. Están disponibles en Visual Studio Marketplace dentro de Visual Studio.

Versión 1.0.4

Se trata de una versión de mantenimiento del SDK de aplicaciones de Windows que incluye correcciones de errores críticos de la versión 1.0.

Correcciones de errores (1.0.4)

  • Se ha corregido un problema que hacía que AppBars, cuando se usaba como Page.TopAppBar o Page.BottomAppBar, no se mostrara en pantalla.
  • Se ha corregido un problema que hacía que las aplicaciones con un nombre de paquete de 12 caracteres o menos que usan un control WinUI de MUXControls.dll se bloquearan inmediatamente. Para más información, consulte el problema 6360 en GitHub.
  • Se han corregido problemas de entrada táctil con los métodos abreviados de teclado y otros escenarios. Para más información, consulte el problema 6291 en GitHub.
  • Se ha corregido un problema que hacía que las aplicaciones empaquetadas con MSIX o implementadas como independientes no se implementaran.
  • Se ha corregido un problema que hacía que las aplicaciones se bloquearan algunas veces durante una operación de arrastrar y colocar. Para obtener más información, consulte el problema 7002 en GitHub.

Versión 1.0.3

Se trata de una versión de mantenimiento del SDK de aplicaciones de Windows que incluye correcciones de errores críticos de la versión 1.0.

Correcciones de errores (1.0.3)

  • Se ha corregido un problema que hacía que las aplicaciones de C# con WebView2 se bloquearan al iniciarse cuando C/C++ Runtime (CRT) no estaba instalado.
  • Se han corregido problemas de entrada táctil con los métodos abreviados de teclado y otros escenarios. Para más información, consulte el problema 6291 en GitHub.

Nota: Normalmente no agregamos funcionalidad en una versión de mantenimiento, pero la corrección de WebView2 de esta versión nos exigía actualizar a la versión más reciente del SDK de WebView2 (1020.46 a 1185.39). Consulte Notas de la versión del SDK de WebView2 para más información sobre WebView2 1.0.1185.39 y Distribución de la aplicación y el entorno de ejecución de WebView2 para más información sobre el entorno de ejecución de WebView2.

Versión 1.0.2

Se trata de una versión de mantenimiento del SDK de aplicaciones de Windows que incluye correcciones de errores críticos de la versión 1.0.

Correcciones de errores (1.0.2)

  • Se ha corregido un problema de ciclo de diseño que hacía que una aplicación se bloqueara al desplazarse al final de un control ListView. Para más información, consulte el problema 6218 en GitHub.
  • Se ha corregido un problema que hacía que las aplicaciones de C# se bloquearan cuando C/C++ Runtime (CRT) no estaba instalado. Sin embargo, el CRT sigue siendo necesario para las aplicaciones de C# que usan WebView2. Para más información, consulte el problema 2117 en GitHub.
  • Se ha corregido un problema por el que las aplicaciones con MSIX de un solo proyecto no generaban un archivo .appinstaller. Para más información, consulte el problema 1821 en GitHub.
  • Se ha corregido un problema que hacía que las aplicaciones de WinUI no admitieran .NET 6 dotnet build.

Versión 1.0.1

Se trata de una versión de mantenimiento del SDK de aplicaciones de Windows que incluye correcciones de errores críticos y compatibilidad con varias ventanas de la versión 1.0.

Correcciones de errores (1.0.1)

  • Se ha corregido un problema que hacía que MddBootstrapAutoinitializer no se compilara con ImplicitUsings habilitado. Para más información, consulte el problema 1686 en GitHub.
  • Se ha corregido un problema que hacía que el foco en WebView2 se perdiera inesperadamente y causara problemas de entrada y selección. Para obtener más información, consulte los problemas 5615 y 5570 en GitHub.
  • Se ha corregido un problema que hacía que la barra de herramientas en la aplicación de Visual Studio fuera inaccesible al usar una barra de título personalizada en una aplicación de WinUI 3.
  • Se ha corregido un problema que hacía que el diseño de ajuste no apareciera al usar una barra de título personalizada en una aplicación de WinUI 3. Para obtener más información, consulte los problemas 6333 y 6246 en GitHub.
  • Se ha corregido un problema que provocaba una excepción al establecer la propiedad Window.ExtendsContentIntoTitleBar cuando se ha llamado a Window.SetTitlebar con un objeto UIElement todavía cargando.
  • Se ha corregido un problema por el que las aplicaciones MSIX de un solo proyecto no admitían dotnet build.
  • Se ha corregido un problema que hacía que las aplicaciones sin empaquetar no se instalaran después de instalar una aplicación empaquetada. Para más información, consulte el problema 1871 en GitHub.
  • Se ha corregido un problema que reduce el rendimiento durante las operaciones de arrastre del mouse.
  • Se ha corregido un bloqueo al llamar a GetWindowIdFromWindow() en aplicaciones sin empaquetar. Para más información, consulte la explicación 1891 en GitHub.

Las limitaciones y los problemas conocidos de la versión 1.0 también se aplican a la versión 1.0.1.

Además, para las aplicaciones con barras de título personalizadas, hemos realizado cambios en esta versión (y se han corregido numerosos problemas) que incluyen correcciones en la ventana de cristal usada para las operaciones de arrastrar y colocar. La recomendación es usar los valores y acciones predeterminadas (pruébelos). Si la barra de título usó márgenes para que los botones de subtítulo predeterminados estuvieran interactivos, se recomienda visualizar la región de arrastre estableciendo el fondo de la barra de título en rojo y ajustando los márgenes para extender la región de arrastre a los controles de subtítulo.

Nuevas características

Hemos estabilizado y habilitado la creación de varias ventanas en el mismo subproceso en aplicaciones WinUI 3. Para obtener más información, consulte el problema 5918.

Versión 1.0

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

WinUI 3

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

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 plantilla "Aplicación en blanco, empaquetada...".
  • Ahora se admite la implementación de aplicaciones de WinUI 3 que no están empaquetadas en las versiones 1809 y posteriores de Windows. Consulte Creación del primer proyecto de WinUI 3 (SDK de Aplicaciones para Windows) para obtener más información.
  • Los proyectos de WinUI 3 ahora pueden establecer su versión de destino hasta Windows 10, versión 1809. Anteriormente, solo podían establecerla hasta la versión 1903.
  • En la barra de herramientas de la aplicación, Recarga activa y el Árbol visual dinámico para aplicaciones empaquetadas de WinUI se admiten en Visual Studio 2022, Preview 5 y con disponibilidad general.

Limitaciones importantes:

  • Problemas conocidos de las aplicaciones WinUI empaquetadas y sin empaquetar:

    • Error en tiempo de ejecución en aplicaciones de C++ o C# que hacen referencia a un componente de Windows Runtime de C++:

      • Para resolverlo, agregue el destino siguiente al final del archivo .vcxproj del componente de Windows Runtime:
      <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>
      • El error esperado será similar a Error de origen de WinRT: 0x80004005 : "No se puede encontrar el recurso de "ms-appx:///BlankPage.xaml".

  • Problemas conocidos de las aplicaciones WinUI con MSIX de un solo proyecto (plantilla Aplicación en blanco, empaquetada):

    • El elemento de menú Empaquetar y publicar no aparece hasta que reinicia Visual Studio: al crear una nueva aplicación con MSIX de proyecto único en Visual Studio 2019 y Visual Studio 2022 mediante la plantilla de proyecto Aplicación en blanco, empaquetada (WinUI 3 en escritorio), el comando para publicar el proyecto no aparece en el menú hasta que cierra Visual Studio y lo vuelve a abrir.
    • Una aplicación de C# con MSIX de un solo proyecto no se compilará sin tener instalado el componente opcional "Herramientas de la Plataforma universal de Windows de C++ (v14x)". Consulte Instalación de herramientas del SDK de aplicaciones de Windows para más información.
    • Posible error en tiempo de ejecución en una aplicación con MSIX de un solo proyecto que consume tipos definidos en un componente de Windows Runtime al que se hace referencia: para resolverlo, agregue manualmente entradas de clase activables a 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 3 que no están empaquetadas (aplicaciones sin empaquetar):

  • Problemas conocidos para empaquetar e implementar aplicaciones de WinUI:

    • El comando Package no se admite en aplicaciones WinUI con MSIX de un solo proyecto (plantilla Aplicación en blanco, empaquetada). En su lugar, use el comando Package & Publish para crear un paquete de MSIX.
    • Para crear un paquete NuGet a partir de una biblioteca de clases de C# con el comando Pack, asegúrese de que el objeto Configuration activo sea Release.
    • El comando Pack no se admite en componentes de Windows Runtime de C++ (v14x) para crear un paquete NuGet.

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

Basado en ventanas

El SDK de aplicaciones de Windows proporciona una clase AppWindow que evoluciona la clase en versión preliminar Windows.UI.WindowManagement.AppWindow anterior y que está disponible para todas las aplicaciones de Windows, como Win32, WPF y WinForms.

Nuevas características:

  • AppWindow 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 hospeda el contenido y representa la entidad con la que los usuarios interactúan cuando cambian el tamaño y mueven la aplicación en la pantalla. Para los desarrolladores familiarizados con Win32, AppWindow se puede ver como una abstracción de alto nivel de HWND.
  • DisplayArea representa una abstracción de alto nivel de HMONITOR y sigue los mismos principios que AppWindow.
  • DisplayAreaWatcher permite a un desarrollador observar los cambios en la topología de visualización y las clases DisplayArea que actualmente se definen en el sistema.

Para obtener más información, consulte Administración de ventanas de aplicaciones (SDK de Aplicaciones para Windows).

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: PointerPoint, PointerPointProperties y PointerEventArgs para admitir la recuperación de información de eventos de puntero con las API de entrada XAML.
  • API InputPointerSource: representa un objeto que está registrado en la entrada del puntero de informe y proporciona el 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.
  • GestureRecognizer API: permite a los desarrolladores reconocer determinados gestos, como arrastrar, mantener presionado y hacer clic cuando se les proporciona información de puntero.

Limitaciones importantes:

  • Se han quitado todas las funciones de fábrica estáticas de la clase PointerPoint: GetCurrentPoint, GetCurrentPointTransformed, GetIntermediatePoints, y GetIntermediatePointsTransformed.
  • El SDK de aplicaciones para Windows no admite la recuperación de objetos PointerPoint con id. de puntero. En su lugar, puede usar la función de miembro de la clase PointerPoint GetTransformedPoint para recuperar una versión transformada de un objeto PointerPoint existente. Para puntos intermedios, puede usar las funciones miembro de PointerEventArgsGetIntermediatePoints y GetTransformedIntermediatePoints.
  • El uso directo de la API del SDK de plataforma Windows.UI.Core.CoreDragOperation no funcionará con aplicaciones WinUI.
  • Las propiedades de la clase PointerPointRawPosition y ContactRectRaw se quitaron porque hacían referencia a valores no previstos, que eran los mismos que los valores normales del sistema operativo. Use Position y ContactRect en su lugar. La predicción del 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 incorporado al SDK de aplicaciones para Windows para su uso por tipos de aplicaciones de escritorio, especialmente aplicaciones de consola sin empaquetar, aplicaciones Win32, aplicaciones Windows Forms y aplicaciones WPF. La implementación del SDK de aplicaciones para Windows de estas características no se puede usar en aplicaciones para UWP, ya que hay características equivalentes en la propia plataforma UWP.

Importante

Si está trabajando en una aplicación para UWP, consulte Migración de UWP al SDK de Aplicaciones para Windows.

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

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

Consideraciones importantes:

  • Activación enriquecida: GetActivatedEventArgs

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

  • 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 habilitarlo, la aplicación debe definir DISABLE_XAML_GENERATED_MAIN y escribir un 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 a una llamada asincrónica si la aplicación se ejecuta en un STA. Para Windows Forms y aplicaciones WinUI de C#, puede declarar Main como asincrónico, si es necesario. En el caso de las aplicaciones WinUI de C++ 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 bloquee el STA.
    • Para obtener más información, consulte Creación de instancias de aplicaciones con la API del ciclo de vida de la aplicación.

  • Notificaciones de energía y estado

Problema conocido:

  • Las asociaciones de tipo de archivo codifican incorrectamente %1 para que sean %251 al establecer la plantilla de la línea de comandos del controlador Verb, que bloquea las aplicaciones Win32 sin empaquetar. Como una solución alternativa, puede editar manualmente el valor del Registro para que sea %1 en su lugar. Si la ruta de acceso del archivo de destino tiene un espacio, se producirá un error y no habrá 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 el registro y volver a registrarla hace que la aplicación se bloquee

DWriteCore

DWriteCore es la implementación del SDK de aplicaciones para Windows 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 y diseño Unicode. DWriteCore es una forma de DirectWrite que se ejecuta en versiones de Windows hasta Windows 10, versión 1809 (10.0; versión de compilación 17763), y que le permite su uso en varias plataformas.

Características:

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 definidas 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 más información, consulte Introducción a BranchCache.

MRT Core

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

Limitaciones importantes:

  • En los proyectos de .NET, los archivos de recursos copiados y pegados en la carpeta del proyecto no se indexan con F5 si la aplicación ya se ha compilado. Como solución alternativa, vuelva a compilar 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 UI de Visual Studio, es posible que los archivos no se indexen de forma predeterminada. Consulte el problema 1786 para obtener más información. Para solucionar este problema, quite las entradas siguientes del 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 compila correctamente. Para solucionar este problema, agregue los 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:

Limitaciones importantes:

  • El contenedor .NET para la API del programa previo solo está diseñado para que lo usen las aplicaciones .NET sin empaquetar para simplificar el acceso al SDK de aplicaciones para Windows.
  • 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 del 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 primero ejecutando WindowsAppRuntimeInstall.exe. De lo contrario, se producirá un error NOT_FOUND debido a que Visual Studio no implementa el marco x64, que normalmente se produce a través de la implementación de Store o la instalación de prueba.

Otros problemas conocidos y limitaciones

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

  • Actualización de .NET 5 a .NET 6: al actualizar en la UI de Visual Studio, es posible que se produzcan 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 proyecto único de C# no se compila si las herramientas de UWP de C++ no están instaladas. Si tiene un proyecto MSIX de un solo proyecto de C#, deberá instalar el componente opcional Herramientas de la plataforma universal de Windows de C++ (v14x).

  • El lenguaje posterior VSIX no se instala en Visual Studio 2019 si hay instaladas varias versiones de Visual Studio 2019. Si tiene varias versiones de Visual Studio 2019 instaladas (por ejemplo, la versión y la versión preliminar) e instala el SDK de aplicaciones para Windows VSIX para C++ y C#, se producirá un error en la segunda instalación. Para resolverlo, desinstale las herramientas de empaquetado de MSIX para Visual Studio 2019 después del primer lenguaje VSIX. Vea estos comentarios para obtener información adicional sobre este problema.

  • Una alternativa a DispatcherQueue.TryEnqueue (para reanudar la ejecución en el subproceso de cola del distribuidor) es usar la función auxiliar resume_foreground en la Biblioteca de implementación de Windows (WIL):

    1. Agregue una referencia al proyecto al paquete NuGet Microsoft.Windows.ImplementationLibrary.
    2. Agregue #include <wil/cppwinrt_helpers.h> a pch.h.
    3. Agregue #include <winrt/Microsoft.UI.Dispatching.h> a pch.h.
    4. Ahora co_await wil::resume_foreground(your_dispatcherqueue);.