Estrategia de migración general

  • Artículo

Introducción

Windows App SDK proporciona un amplio conjunto de API de Windows –con implementaciones desacopladas del sistema operativo y lanzadas para los desarrolladores a través de paquetes NuGet. Como desarrollador con una aplicación de Plataforma universal de Windows (UWP), puede hacer un gran uso de su conjunto de aptitudes existente y su código fuente moviendo la aplicación al SDK de Aplicaciones para Windows.

Con el SDK de Aplicaciones para Windows 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 de Windows Runtime (WinRT) se pueden usar en aplicaciones SDK de Aplicaciones para Windows. 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 la Biblioteca de interfaz de usuario de Windows (WinU) o mediante interfaces COM de WinRT disponibles en la SDK de Aplicaciones para Windows.

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 API de Windows Runtime no compatibles con aplicaciones de escritorio. Las aplicaciones de la SDK de Aplicaciones para Windows son un tipo de aplicación de escritorio. Otros tipos de aplicaciones de escritorio incluyen aplicaciones de escritorio de .NET y aplicaciones de escritorio C/C++ Win32. Ese tema está destinado a los desarrolladores desean migrar a cualquier unión de esos diferentes tipos de aplicaciones de escritorio, que incluye (entre otras) aplicaciones SDK de Aplicaciones para Windows.

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 la SDK de Aplicaciones para Windows, o simplemente para iniciar una discusión, use el botón Este producto. También puede iniciar una discusión en la pestaña Discusiones del repositorio de GitHub de WindowsAppSDK. 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é realiza la migración al SDK de Aplicaciones para Windows?

El SDK de Aplicaciones para Windows le ofrece una oportunidad para mejorar su aplicación con nuevas características de plataforma, así como con la moderna Biblioteca de interfaz de usuario de Windows 3 (WinUI 3), desarrollada y diseñada para complacer a los usuarios.

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

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

  • Plataforma y controles de la interfaz de usuario (UI) más recientes, como Biblioteca de interfaz de usuario de Windows (WinUI) 3 y WebView2.
  • Una sola superficie de API en distintas 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.
  • Compatibilidad con .NET
  • Compatible con versiones anteriores a Windows 10, versión 1809.
  • Entorno de tiempo de ejecución mejorado. Consulte Contenedor MSIX.

Para obtener más información, vea SDK de Aplicaciones para Windows.

Introducción al proceso de migración

Nota:

Puede pensar en la versión de UWP de la aplicación que quiere migrar como la solución o proyecto de origen (es el origen del proceso de migración). La versión de SDK de Aplicaciones para Windows es la solución de destino (es el destino del proceso de migración).

Instalación de VSIX del SDK de Aplicaciones para Windows

Descargue el instalador de la extensión (VSIX) de Visual Studio del SDK de Aplicaciones para Windows desde el canal de versión estable del SDK de Aplicaciones para Windows y ejecútelo para instalarlo.

Creación de un nuevo proyecto

En Visual Studio, Cree su primer proyecto de WinUI 3. Por ejemplo, use la plantilla de proyecto Aplicación en blanco, empaquetada (WinUI 3 en escritorio). Puede encontrar esa plantilla de proyecto en el cuadro de diálogo Crear un nuevo proyecto eligiendo lenguaje: C# o C++; plataforma: SDK de Aplicaciones para Windows; tipo de proyecto: WinUI o Escritorio.

Verá dos proyectos en Explorador de soluciones: uno está calificado como (Escritorio) y el otro como (Paquete).

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 que DetailPage tiene una dependencia del modelo Photo. Si fuéramos a seguir esa ruta de acceso, podríamos tener constantes interrupciones (cambiar al trabajo en cada dependencia detectada). Ciertamente, no esperaríamos obtener una compilación limpia hasta que hubiéramos seguido todas las dependencias y básicamente realizado la portabilidad de todo el proyecto en un salto gigante.

Por otro lado, empezaríamos con la parte del proyecto que no depende de nada más, y trabajaríamos desde allí hacia fuera (de la parte menos dependiente a la más dependiente), y entonces podríamos centrarnos en cada pieza. Y también podríamos lograr una compilación limpia después de migrar cada pieza y de esa manera confirmar que el proceso de migración se está realizando correctamente.

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:

  • (Opción recomendada) puede copiar los propios archivos (mediante el 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 proyecto de destino y contienen código fuente específico del SDK de Aplicaciones para Windows. Para aquellos tendrá que combinar el código fuente que ya está allí con el código fuente del proyecto de origen.
  • O bien, puede usar Visual Studio para crear nuevos archivos Page (como MainPage.xaml y MainPage.xaml.cs) en el proyecto de destino y, a continuación, copiar el contenido de esos archivos de código fuente desde el proyecto de origen al proyecto de destino. Para un proyecto de C++/WinRT, esta opción implica muchos más pasos.

Vea 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, los archivos de código subyacente para las vistas XAML se denominan del formulario MainPage.h y MainPage.cpp. Pero en un SDK de Aplicaciones para Windows de C++/WinRT, tendrá que cambiar el nombre por MainPage.xaml.h y MainPage.xaml.cpp.

En un proyecto de UWP de C++/WinRT, al migrar una vista XAML hipotética (en el sentido de modelos, vistas y modelos de vista) denominada MyPage, en MyPage.xaml.cpp tendrá que 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 del proyecto migrado

Al migrar, 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. Cuando copie el código fuente desde el proyecto de origen al proyecto de destino, es posible que tenga que cambiar los nombres de los espacios de nombres 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 Una migración del SDK de Aplicaciones para Windows 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 proyecto de origen al de destino, copiamos archivos completos mediante Explorador de archivos. El nombre del proyecto o espacio de nombres de origen es PhotoLab y el nombre del proyecto o 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 proyecto de origen.

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

Por ejemplo, en el caso práctico Migración de un SDK de Aplicaciones para 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 referencias al mismo paquete NuGet en el proyecto de destino.