Compartir a través de

Estrategia de migración general

Introducción

El Windows App SDK proporciona un amplio conjunto de API de Windows, con implementaciones que se desacoplan del sistema operativo y se publican para desarrolladores a través de NuGet paquetes. Como desarrollador con una aplicación de Universal Windows Platform (UWP), puedes hacer un gran uso de tu conjunto de aptitudes existente y tu código fuente moviendo la aplicación a la Windows App SDK.

Con el Windows App SDK puede incorporar las características más recientes del entorno de ejecución, el lenguaje y la plataforma en la aplicación. Dado que cada aplicación es diferente y, por tanto, también lo son sus requisitos y preferencias, hay muchas maneras diferentes de abordar el proceso de migración del código fuente de la aplicación. Pero el enfoque de alto nivel y los cambios de código necesarios para varias áreas de características son similares. Por lo tanto, en este tema revisaremos las estrategias sobre cómo puede abordar la migración de la aplicación, así como más información (y limitaciones) sobre determinadas áreas de características. Por lo tanto, consulte también Qué se admite al migrar de UWP a WinUI 3.

La mayoría de las API Windows Runtime (WinRT) se pueden usar en aplicaciones Windows App SDK. Pero hay algunas que no se admiten en las aplicaciones de escritorio o tienen restricciones.

  • Las API que tienen dependencias en las características de la interfaz de usuario y que se han diseñado para su uso solo en aplicaciones para UWP.
  • API que requieren la identidad del paquete. Estas API solo se admiten en aplicaciones de escritorio que se empaquetan mediante MSIX.

Para esas API, le mostraremos las alternativas que se deben usar. La mayoría de esas alternativas están disponibles en WinUI o a través de interfaces COM de WinRT que están disponibles en el Windows App SDK.

Por ejemplo, veremos determinados escenarios de interfaz de usuario en los que tendrá que realizar un seguimiento del objeto de ventana principal y usar varias API basadas en HWND y patrones de interoperación, como IInitializeWithWindow::Initialize.

Nota:

Consulte también Windows Runtime APIs no son admitidas en aplicaciones de escritorio. aplicaciones de Windows App SDK son un tipo de aplicación de escritorio. Otros tipos de aplicaciones de escritorio incluyen .NET aplicaciones de escritorio y aplicaciones de escritorio Win32 de C/C++. La audiencia de ese tema son los desarrolladores que desean migrar a cualquier unión de esos distintos tipos de aplicaciones de escritorio, incluidas (pero no limitadas a) aplicaciones de Windows App SDK.

Nos encantaría escuchar sus comentarios sobre esta guía de migración y sobre su propia experiencia de migración. Use la sección Comentarios justo al pie de esta página de la siguiente manera:

  • Para preguntas y comentarios sobre el Windows App SDK, o simplemente para iniciar una discusión, use el botón This product. También puede iniciar una discusión sobre la pestaña Discussions del repositorio WindowsAppSDK GitHub. Con esos canales, puede indicarnos también qué problema está intentando resolver, cómo ha intentado resolverlo hasta ahora y cuál sería la solución ideal para la aplicación.
  • Para obtener comentarios sobre información incorrecta o que falta en esta guía de migración, use el botón Esta página.

¿Por qué migrar al Windows App SDK?

El Windows App SDK te ofrece una oportunidad para mejorar tu aplicación con nuevas características de plataforma, así como con la moderna biblioteca Windows UI 3 Library (WinUI), que está desarrollada y diseñada para complacer a los usuarios.

Además, el Windows App SDK es compatible con versiones anteriores; admite aplicaciones hasta Windows 10, versión 1809 (10.0; Compilación 17763): también conocida como actualización de Windows 10 de octubre de 2018.

La propuesta de valor de migrar el SDK de aplicaciones de Windows es múltiple. A continuación, se indican algunas consideraciones:

  • Plataforma y controles de la interfaz de usuario (UI) más recientes, como WinUI 3 y WebView2.
  • Una única superficie de API en plataformas de aplicaciones de escritorio.
  • Cadencia de versiones más frecuente que se liberan por separado de Windows.
  • Una experiencia coherente entre las versiones de Windows.
  • .NET compatibilidad.
  • Compatible con versiones anteriores hasta Windows 10, versión 1809.
  • Entorno de tiempo de ejecución mejorado. Consulte Contenedor MSIX.

Para obtener más información, consulta Windows App SDK.

Introducción al proceso de migración

Nota:

Puedes pensar en la versión UWP de la aplicación que deseas migrar como la solución/proyecto origen (es el origen del proceso de migración). La versión Windows App SDK es la solución target (es la solución target del proceso de migración).

Instalar el VSIX de Windows App SDK

Descargue la versión de Windows App SDK más reciente de Windows App SDK descargas y ejecute para instalarla.

Crear un nuevo project

En Visual Studio, Crea tu primer proyecto de WinUI. Por ejemplo, use la plantilla de proyecto Aplicación en blanco de WinUI (Empaquetada). Puede encontrar esa plantilla de project en el cuadro de diálogo Crear una nueva project eligiendo idioma: C# o C++; plataforma: Windows App SDK; project tipo: WinUI o Desktop.

Verá dos proyectos en Solution Explorer: uno está calificado como (Desktop) y el otro como (Package).

Migración del código con las dependencias mínimas primero

Para ilustrar esta recomendación, tomemos el caso práctico de PhotoLab como ejemplo. Para la aplicación de ejemplo PhotoLab, es posible que un enfoque obvio sea empezar migrando MainPage, al tratarse de una parte tan importante y destacada de la aplicación. Pero si hiciéramos eso, pronto nos daríamos cuenta de que MainPage tiene una dependencia de la vista DetailPage; y luego DetailPage tiene una dependencia del modelo Photo. Si siguiéramos ese camino, podríamos estar constantemente interrumpiéndonos (cambiando para trabajar en cada nueva dependencia descubierta). Ciertamente no esperaríamos obtener una build limpia hasta que persiguiéramos todas las dependencias y esencialmente portáramos todo el proyecto en un solo movimiento.

Por otro lado, deberíamos comenzar con la parte del proyecto que no depende de nada más y trabajar desde allí hacia las otras (de la parte menos dependiente a la más dependiente), entonces podríamos centrarnos en cada parte por separado. Y también podríamos lograr una compilación limpia después de migrar cada pieza y así confirmar que el proceso de migración sigue el curso previsto.

Por lo tanto, al migrar sus propias aplicaciones, le recomendamos que migre primero el código con las menores dependencias.

¿Copiar archivos o copiar el contenido de los archivos?

Al migrar, por supuesto copiará los archivos de recursos (y no el contenido del archivo de recursos). ¿Pero qué ocurre con los archivos de código fuente? Como ejemplo, vamos a tomar de nuevo la clase MainPage del caso práctico de PhotoLab y el caso práctico de Photo Editor.

C#. En la versión de C# (PhotoLab), MainPage se compone de los archivos de código fuente MainPage.xaml y MainPage.xaml.cs.

C++/WinRT. En la versión de C++/WinRT (Photo Editor), MainPage se compone de los archivos de código fuente MainPage.xaml, MainPage.idl, MainPage.h y MainPage.cpp.

Por lo tanto, puede elegir entre estas dos opciones:

  • (Recomendado) puede copiar los propios archivos (usando Explorador de Archivos) y, a continuación, agregar las copias al proyecto de destino. Las excepciones a esta recomendación son archivos como App.xaml y App.xaml.cs, ya que esos archivos ya existen en el project de destino y contienen código fuente específico del Windows App SDK. Para aquellos necesitarán fusionar el código fuente que ya está allí con el código fuente del proyecto de origen.
  • También puede usar Visual Studio para crear nuevos archivos Page (como MainPage.xaml y MainPage.xaml.cs) en el project de destino, y, a continuación, copie el contents de esos archivos de código fuente desde el project de origen al project de destino. Para un project de C++/WinRT, esta opción implica muchos más pasos.

Consulte también la sección MainPage y MainWindow.

Diferencias de nombre de carpeta y archivo (C++/WinRT)

En un proyecto de UWP de C++/WinRT, a los archivos de código detrás para las vistas XAML se les da el nombre con el formato MainPage.h y MainPage.cpp. Pero en un Windows App SDK de C++/WinRT, tendrás que cambiar el nombre a MainPage.xaml.h y MainPage.xaml.cpp.

En un proyecto UWP de C++/WinRT, al migrar una vista XAML hipotética (en el sentido de modelos, vistas y modelo de vista) denominada MyPage, en MyPage.xaml.cpp deberá agregar #include "MyPage.g.cpp" inmediatamente después de #include "DetailPage.xaml.h". Y para un modelo hipotético denominado MyModel, en MyModel.cpp agregar #include "MyModel.g.cpp" inmediatamente después de #include "MyModel.h". Para ver un ejemplo, consulte Migración del código fuente de DetailPage.

Si cambia el nombre de su proyecto migrado

Durante la migración, puede optar por asignar al proyecto de destino un nombre diferente al del proyecto de origen. Si lo hace, esto afectará al espacio de nombres predeterminado dentro del proyecto de origen. A medida que copie el código fuente desde el proyecto de origen al proyecto de destino, es posible que tenga que cambiar los namespaces que se mencionan en el código fuente.

Cambiar el nombre del proyecto (y, en consecuencia, el nombre del espacio de nombres predeterminado) es algo que hacemos, por ejemplo, en el caso práctico de una migración del Windows App SDK de la aplicación de ejemplo PhotoLab para UWP (C#). En ese caso práctico, en lugar de copiar el contenido del archivo desde el origen al proyecto de destino, copiamos archivos completos mediante el Explorador de Archivos. El nombre del proyecto/espacio de nombres de origen es PhotoLab y el nombre del proyecto/espacio de nombres de destino es PhotoLabWinUI3. Por lo tanto, necesitamos buscar PhotoLab en el contenido de los archivos de código fuente que hemos copiado y cambiarlo a PhotoLabWinUI3

En ese caso práctico concreto, hemos realizado esos cambios en App.xaml, App.xaml.cs, MainPage.xaml, MainPage.xaml.cs, DetailPage.xaml, DetailPage.xaml.cs, ImageFileInfo.cs y LoadedImageBrush.cs.

Instale los mismos paquetes NuGet que se instalaron en el project de origen

Una tarea durante el proceso de migración es identificar los paquetes NuGet en los que el project de origen tiene dependencias. A continuación, instale esos mismos paquetes NuGet en el proyecto de destino.

Por ejemplo, en el caso práctico Una migración del SDK de aplicaciones de Windows de la aplicación de ejemplo PhotoLab para UWP (C#), el proyecto de origen contiene referencias al paquete NuGet Microsoft.Graphics.Win2D. Por lo tanto, en ese caso práctico agregamos una referencia al mismo paquete NuGet al proyecto de destino.

  • Last updated on