¿Cuáles son algunas técnicas para migrar una aplicación MFC grande a WPF/.NET?

Question

Actualmente estoy trabajando en una aplicación MDI MFC heredada muy grande. Tiene una gran cantidad de elementos de IU: barras de herramientas acoplables, controles de árbol personalizados, menús contextuales, etc. Es una aplicación de procesamiento de imágenes, por lo que las vistas principales se renderizan usando DirectX y OpenGL. El producto tiene aproximadamente 10 años y una de las prioridades aquí es actualizar su aspecto.

Sabiendo que Microsoft ha hecho un buen trabajo al proporcionar interoperabilidad entre C++/MFC y .NET, pensé que tendría sentido migrar la base de código de forma incremental. Lo que estoy luchando ahora es por dónde empezar.

Un enfoque es extraer el marco MFC con WPF y reutilizar la mayor cantidad de código C++ que podamos. Esto nos permitirá maximizar los beneficios de la arquitectura de WPF, pero significará un largo período de desarrollo hasta que seamos completamente funcionales de nuevo.

Otro enfoque es reemplazar los controles MFC de uno en uno con sus homólogos de WPF. Esto nos permitirá trabajar incrementalmente. Mi preocupación con este enfoque es que significa que habrá una gran cantidad de puntos de conexión entre el código administrado y no administrado, y no estoy seguro por dónde empezar reemplazando elementos como el menú principal y las barras de herramientas.

¿O hay otra opción aquí que no estoy viendo?

Cualquier sugerencia o enlaces a información sobre este tema serán apreciados.

Actualización: DavidK planteó algunas preguntas excelentes por lo que estoy agregando las motivaciones detrás de esto.

1) El desarrollo futuro del producto

Este producto aún está en desarrollo activamente con nuevas características a agregarse de manera regular. Pensé que tendría mucho sentido intentar y migrar lentamente hacia C#/WPF. En mi experiencia limitada con C#/WPF, encontré que las ganancias de productividad son increíbles sobre el trabajo en C++/MFC.

La otra gran cosa que estamos obteniendo con WPF es la capacidad de aprovechar los sistemas de varias cabezas. Las aplicaciones de MFC están limitadas a un único marco de nivel superior, por lo que es muy difícil aprovechar múltiples monitores.

2) Retención de los empleados y el reclutamiento

Se está haciendo cada vez más difícil encontrar desarrolladores que están dispuestos a trabajar en MFC. También es importante para el desarrollo profesional de los desarrolladores actuales obtener exposición a las tecnologías más nuevas.

Answer 1

Revisando esto porque he reemplazado con éxito nuestra UI de MFC de nivel superior (el marco principal, las ventanas y las barras de herramientas) con WPF.

Como resultado, nuestro código de dibujo central simplemente necesita entregarse un HWND para procesar. Esto facilitó la reutilización de la mayor parte de nuestra base de código C++ existente.

He aquí un resumen rápido de las piezas clave del enfoque Tomé:

• utiliza la clase de .NET HwndHost para acoger un HWND para el C++ código de dibujo para representar en
• Creado envoltorios C++/CLI para cualquier código nativo de C++ que deba exponerse al código UI de WPF/C#
• Salió de la mayoría de los cuadros de diálogo de MFC tal como están en el código nativo de C++. Esto minimiza la cantidad de trabajo necesario para finalizar la IU. Los cuadros de diálogo de MFC se pueden migrar a WPF a lo largo del tiempo.

Como una nota al margen, estamos usando SandDock y SandRibbon de Divelements y hemos estado muy contentos con ellos hasta ahora.

Answer 2

Tuve que hacer lo mismo en un proyecto usando WinForms antes. Necesitábamos migrar nuestro proyecto MFC a .NET 1.1 y decidimos tomar todas las funciones principales de la aplicación MFC y escribir envoltorios administrados en todas ellas. Luego escribimos un front end de WinForms y conectamos bit a bit el código heredado de C++. Creo que tomamos la decisión correcta a largo plazo. No puedo imaginar cómo lo habríamos hecho si hubiéramos intentado preservar el front-end de MFC al mismo tiempo.

Answer 3

Creo que tiene un buen manejo de las estrategias. Tenga en cuenta que un posible punto de dolor en la migración a WPF es que no todos los controles tienen un mango. Desafortunadamente, este es el escenario de interoperabilidad más torpe. AFAIK, la única forma de interoperar con MFC y WPF es pasar por WindowsFormsHost. El paradigma WPF también es radicalmente diferente de MFC/WinForms, por lo que puede haber algunos problemas de traducción allí.

Teniendo en cuenta su gran, pero funcional, código heredado, probablemente argumentaría a favor de su segundo enfoque. Comience con un control a la vez y hágalo WPF-y. Cree una interfaz bien definida entre su nuevo control administrado y la base de código subyacente, luego trabaje contra esa interfaz. Si lo hace de a uno por vez, trabajará con un perfil de riesgo más bajo con respecto a la curva de aprendizaje de WPF (que es bastante pronunciada, iho).

Siento que es importante tener en cuenta que probablemente sugeriría el enfoque anterior si fuera a WinForms. El paradigma más cercano y la curva de aprendizaje relativamente suave serían mucho más fáciles de trabajar a través de todo a la vez.

Answer 4

FWIW, mientras tanto, podría usar el paquete de características MFC (disponible con VS2008 SP1) para darle a su aplicación un aspecto Office 2007 y sentirse bastante rápido (incluso puede agregar una cinta si es algo que sus usuarios desean, aunque esto sería más complicado.) Actualicé la interfaz de usuario para una aplicación MFC antigua usando estas nuevas clases en un solo día y ahora, para ser justos, se ve fantástica, y mis usuarios están muy satisfechos (puede admitir una gran cantidad de apariencia y esquemas de color.) MS optó por el kit de herramientas BCG, pero hay otros disponibles si desea pagar una pequeña cantidad de dinero (CodeJock, por ejemplo)

Sé que esto no responde su pregunta, pero si es solo los cambios de UI que está buscando pueden valer la pena.

Answer 5

No creo que haya una manera más fácil que no haya cubierto, aunque probablemente dependerá bastante de qué tan separada esté la lógica subyacente de la capa de la interfaz de usuario.

Sin querer parecer negativo: ¿estás seguro de que valdrá la pena el esfuerzo? Si estuviera escribiendo una gran aplicación desde cero, no comenzaría ahora con C++ y MFC, pero al ver dónde estás, ¿qué ganarías realmente al reescribirlo? ¿Agregará eso una característica nueva y única que los usuarios pagarán? ¿Hay usuarios a los que cortará que no podrán ejecutar la nueva versión? No puedo evitar sospechar que obtendrás un retorno de la inversión mucho más grande al observar algunas cosas relativamente simples que podrías hacer para mejorar la apariencia de la aplicación tal como es. Por ejemplo, ¿tiene un manifiesto de estilo XP para que los controles comunes obtengan el aspecto de XP? ¿Pasarían unos días dedicados a la actualización de bits (por ejemplo, utilizando los nuevos diálogos de archivos de estilo) para llegar a un nuevo aspecto brillante? Tenga en cuenta que incluso Office 2007, la más nueva y brillante, fue implementada por Microsoft con los controles normales de Win32.