Estrategia de migración general

Introducción

El SDK de Aplicaciones para Windows 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 paquetes NuGet. Como desarrollador con una aplicación de Plataforma universal de Windows (UWP), puedes hacer un gran uso de tu conjunto de aptitudes existente y tu 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, 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, consulta 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 algunos que no se admiten en las aplicaciones de escritorio o que 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 empaquetadas mediante MSIX.

Para esas API, le mostraremos qué alternativas usar. La mayoría de esas alternativas están disponibles en la Biblioteca de interfaz de usuario de Windows (WinUI) o a través de interfaces COM de WinRT que están disponibles en el SDK de Aplicaciones para Windows.

Por ejemplo, veremos ciertos 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 API no admitidas en aplicaciones de escritorio. SDK de Aplicaciones para Windows aplicaciones son un tipo de aplicación de escritorio. Otros tipos de aplicaciones de escritorio incluyen aplicaciones de escritorio de .NET y aplicaciones de escritorio win32 de C/C++. La audiencia de ese tema es que los desarrolladores desean migrar a cualquier cosa de la unión de esos diferentes tipos de aplicaciones de escritorio, incluidas (pero no limitadas a) SDK de Aplicaciones para Windows aplicaciones.

Nos encantaría escuchar su cuota 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 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, también puede indicarnos 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 la información que falta o es incorrecta en esta guía de migración, use el botón Esta página .

¿Por qué migrar al SDK de Aplicaciones para Windows?

El SDK de Aplicaciones para Windows te ofrece la oportunidad de mejorar tu aplicación con nuevas características de plataforma, así como con la moderna biblioteca de interfaz de usuario de Windows 3 (WinUI 3), que está 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 manifold. 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 plataformas de aplicaciones de escritorio.
  • Cadencia de versiones más frecuente que se publica por separado de Windows.
  • Una experiencia coherente en todas las versiones de Windows.
  • Compatibilidad de .NET.
  • Compatible con versiones anteriores hasta Windows 10, versión 1809.
  • Entorno en tiempo de ejecución mejorado. Consulte Contenedor MSIX.

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

Introducción al proceso de migración

Nota

Puedes considerar la versión de UWP de la aplicación que quieres migrar como 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 de SDK de Aplicaciones para Windows

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

Creación de un nuevo proyecto

En Visual Studio, cree el primer proyecto de WinUI 3. Por ejemplo, use la plantilla de proyecto Aplicación vacía, Empaquetada (WinUI 3 en escritorio). Para encontrar esa plantilla de proyecto en el cuadro de diálogo Crear un proyecto, elija lenguaje: C# o C++; platform: SDK de Aplicaciones para Windows; tipo de proyecto: WinUI o Desktop.

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, vamos a tomar el caso práctico photoLab como ejemplo. Para la aplicación de ejemplo PhotoLab, quizás un enfoque obvio podría ser comenzar mediante la migración de MainPage, ya que es una parte tan importante y destacada de la aplicación. Pero si lo hiciéramos, pronto nos dimos cuenta de que MainPage tiene una dependencia en la vista DetailPage ; y, a continuación, detailPage tiene una dependencia en el modelo photo . Si seguimos esa ruta de acceso, es posible que nos interrumpamos constantemente (cambiando para trabajar en cada dependencia recién detectada). Sin duda, no esperaríamos obtener una compilación limpia hasta que perseguíamos todas las dependencias y esencialmente portamos todo el proyecto en un salto gigante.

Por otro lado, si empezamos con la parte del proyecto que no depende de nada más, y trabajar hacia fuera desde allí (de la parte menos a la más dependiente), entonces podríamos centrarnos en cada pieza de uno en uno. 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 está en marcha.

Por lo tanto, al migrar sus propias aplicaciones, se recomienda migrar código con las dependencias mínimas primero.

¿Copiar archivos o copiar el contenido del archivo?

Al migrar, por supuesto va a 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 photoLab y del caso práctico de Photo Editor.

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

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

Por lo tanto, tiene la opción entre estas dos opciones:

  • (Recomendado) puede copiar los propios archivos (mediante 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 que necesite combinar el código fuente que ya existe con el código fuente del proyecto de origen.
  • O bien, puede usar Visual Studio para crear nuevos archivos de página (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.

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

Diferencias de nombre de archivo y carpeta (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ás que cambiar el nombre de a 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ás que agregar #include "MyPage.g.cpp" inmediatamente después #include "DetailPage.xaml.h"de . Y para un modelo hipotético denominado MyModel, en MyModel.cpp agregue #include "MyModel.g.cpp" inmediatamente después de #include "MyModel.h". Para obtener un ejemplo, vea Migrar el código fuente de DetailPage.

Si cambia el nombre del proyecto migrado

Durante la migración, puede optar por asignar 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 del proyecto de origen en el proyecto de destino, es posible que tenga que cambiar los nombres de espacio de nombres que se mencionan en el código fuente.

Cambiar el nombre del proyecto (y, por lo tanto, el nombre del espacio de nombres predeterminado) es algo que hacemos, por ejemplo, en el caso práctico A SDK de Aplicaciones para Windows migración 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 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, realizamos esos cambios en App.xaml, App.xaml.cs, MainPage.xamlMainPage.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. Después, instale esos mismos paquetes NuGet en el proyecto de destino.

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