Estrategia de migración general

  • Artículo

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 Plataforma universal de Windows (UWP), puedes hacer un gran uso del conjunto de aptitudes existente y el 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 de tiempo de ejecución, lenguaje y plataforma en la aplicación. Dado que cada aplicación es diferente, por lo que 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 Lo que 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 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 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++. El público 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 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 falta de información o la información incorrecta de 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 biblioteca moderna de windows UI 3 (WinUI 3), que se desarrolla y está 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 el 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 la Biblioteca de interfaz de usuario de Windows (WinUI) 3 y WebView2.
  • Una sola superficie de API en plataformas de aplicaciones de escritorio.
  • Cadencia de versión más frecuente que se libera 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 pensar en 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 del VSIX de SDK de Aplicaciones para Windows

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

Creación de un 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 migrando MainPage, ya que es una parte tan importante y destacada de la aplicación. Pero si fueramos a hacerlo, 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 tuviéramos que seguir esa ruta de acceso, podríamos interrumpirnos constantemente (cambiar a trabajar en cada dependencia recién detectada). Sin duda, no esperaríamos conseguir 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 comencemos con la parte del proyecto que no depende de nada más, y trabajemos hacia fuera desde allí (de la parte menos a la más dependiente), entonces podremos centrarnos en cada pieza una a la vez. 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á ejecutando.

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 sobre 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 el 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 (Editor de fotos), 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 está allí 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, deberá cambiar el nombre 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, deberá MyPage.xaml.cpp 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, consulte Migración del 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 desde el proyecto de origen al 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 consiguiente, el nombre del espacio de nombres predeterminado) es algo que hacemos, 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#). 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, es necesario 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.xamlMainPage.xaml.cs, DetailPage.xaml, DetailPage.xaml.cs, , ImageFileInfo.csy 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 Una migración 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 una referencia al mismo paquete NuGet al proyecto de destino.