2011-01-11 5 views
6

Estamos planeando mover algunos de nuestros productos VC++ Legacy a C# con la plataforma .NET. Estoy en el proceso de recopilar la información relavent antes de hacer la propuesta para dar una respuesta optimista y efectiva acercamiento a los clientes. Estoy buscando los siguientes detalles.VC++ to C# guidelines/guidelines/issues

  1. Todas las directrices generales de la migración de VC++ a C# .NET
  2. Cuáles son los temas que un equipo puede enfrentar cuando tomamos esta actividad
  3. ¿Hay enfoques existentes disponibles? Creo que muchos lo habrían intentado, pero es posible que no tengan información detallada, pero consolidar esto en virtud de esto me ayudaría no solo a mí sino a cualquiera que busque esta información.
  4. ¿Algún recurso bueno/válido disponible en internet?
  5. Cualquier sugerencia del equipo de Microsoft si alguna persona de Microsoft en este grupo?
  6. Arquitectura, componentes de los enfoques de diseño, etc.

favor me ayude a obtener esta información, cada centavo que me ayudaría a ganar buen entendimiento ..

Gracias de antemano a los que van a compartir su sabiduría a fondo esta consulta.

+0

@all: más detalles sobre mis productos VC++, este producto consiste en la mayoría de los conceptos de OOP basados ​​en COM con Objective C implementados, esto es casi 17 años de desarrollo de producto. Lo que esencialmente significa mucho código con muchos de los componentes. Recientemente, mi cliente me pidió que le diera una propuesta para fusionar todo este producto y su funcionalidad con la existencia de otro producto .NET y mejorar esas características. – KSH

+0

@all: Esto nos obligó a pensar en un enfoque para abordar el problema. La planificación para identificar COM individuales o DLL que están en VC++ y que pueden ser directamente/a través de la envoltura utilizada dentro de .NET funciona. Planea tocar estos módulos solo cuando sea necesario. Además de la planificación para llevar a cabo la reescritura completa de la interfaz de usuario con nuevos elementos de marco. Más sugerencias sobre UI/Código/conceptos ayudarían a obtener más conocimiento. – KSH

Respuesta

4

Una vez, si tiene una jerarquía de clases complicada, tenga en cuenta que C# no es compatible con la herencia múltiple, por lo que puede tener que replantear la estructura de su programa.

Editar: Otra cosa a tener en cuenta es que el .NET Framework es muy, muy grande. Puede encontrar clases de utilidad en su código de C++ que pueden ser completamente reemplazadas por clases de biblioteca estándar en C#.

14

A menudo, mi mejor consejo es: No lo hagas.

Si tiene un código de C++ limpio y funcionando, no hay razón para reescribirlo. Es muy fácil usar C++/CLI para compilar envolturas alrededor del código heredado para hacerlo utilizable desde C# /. NET.

Este es a menudo un enfoque mejor, más rápido y más seguro. A continuación, puede hacer su nuevo desarrollo en .NET y migrar lentamente cualquier código existente requerido si es realmente necesario hacerlo.

Dicho esto, migrar el código de C++ a C# suele ser una reescritura completa desde cero (a menos que se ajuste como se menciona anteriormente). Esto se debe principalmente a la enorme diferencia en las bibliotecas, no a la diferencia en los idiomas.

.NET Framework proporciona una gran biblioteca de herramientas que pueden y deben cambiar la arquitectura de su código cuando se escribe. Si solo transfiere directamente el C++ al C#, descubrirá que hará muchas cosas de formas no estándar y terminará con un código C# muy difícil de mantener.

Mi sugerencia, basada en mi experiencia, es ajustar primero el código. Luego, si decide que necesita extender cierta funcionalidad, y es poco sólida debido a las envolturas, puede volver a escribir esa parte específica de su código en C# utilizando técnicas y bibliotecas completamente nuevas, y reemplazar C++ pieza por pieza.

+2

El problema con este enfoque es que no se puede ejecutar C++/CLI en contextos de seguridad restringida como Windows Phone. (A menos que use '/ clr: pure', lo que obliga a reescribir todo de todos modos) –

+0

@Billy: Pero tampoco puede usar las mismas bibliotecas en Windows Phone, por lo que realmente va a escribir código nuevo, desde cero de todos modos ... –

+1

@Reed: No discutiendo con eso. Solo decir que "simplemente compilar como C++/CLI y todo estará bien" realmente no es cierto en todos los contextos. Sin embargo, no estoy seguro de lo que quiere decir con las bibliotecas, ya que recuerdo que C++/CLI incluye una versión administrada de la biblioteca estándar de C++. –

2

Algunas cosas que se presentan al instante:

  • asegurarse de que no hay que confundir el C++ "char" y el "char" C#. Probablemente sepas que un "char" en C# no es realmente un primitivo de un byte. Por lo tanto, en el proceso de migración puede confundirse, preste atención que en C# transfiere el C++ "char" a "byte".

  • Como dijo Brennan Vincent, C++ admite multi-herencia, mientras que C# no. Probablemente tendrá que volver a pensar en la jerarquía, si sus clases son "complejas".

  • Los punteros NO son nativos en C# como en C++. De nuevo, depende de cómo escribiste tu aplicación C++ pero puedo apostar que estás usando punteros allí, así que asegúrate de que usesfe se corresponda con los C# porque los maneja de manera diferente y transparente desde el programador (en la mayoría de los casos).

¡Podría agregar algunos más más tarde, buena pregunta!

1

Primero, no tome su código C++ nativo que funciona y compílelo como C++/CLI. Obtendrás resultados horribles En segundo lugar, no tome su código nativo de C++ y trate de traducirlo a C#, al mismo tiempo que observe los lugares para usar las Bibliotecas de clase base, cambie su técnica de acceso a datos y ajuste su paradigma de interfaz de usuario de MFC a WPF. Gastarás MUCHA energía para producir, en el mejor de los casos, lo que tenías antes.

En su lugar, tome su código C++ nativo que funciona y refactorícelo para que tenga una o más bibliotecas de "lógica de negocios". Si ya existen, podrían tener interfaces COM, podrían exponer algunas funciones de tipo "C externo" o podrían exponer algunos métodos de instancia de C++. Sin preocupaciones. Si no existen, tienes dos opciones. Si solo hay un puñado de métodos necesarios para la capa de presentación, y toman cosas simples como cadenas, coloque algunas funciones "C externas" en el lugar como puertas de entrada a la lógica de negocios. Ahora puede llamar a aquellos desde la interfaz de usuario administrada (VB o C#, Windows Forms o WPF, lo que sea) utilizando P/Invoke. Si hay muchos y desea organizarlos, o si necesitan tomar estructuras complejas u objetos, escriba una clase C++/CLI o clases que puedan hablar con las clases nativas de C++ tal como están, al tiempo que exponen clases de "clase de referencia pública". a la interfaz de usuario administrada. C++/CLI simplificará los cálculos y los problemas de por vida.

Para su nueva IU, escríbala desde cero, llamando a la lógica de negocio cuando sea necesario. Use la interfaz de usuario anterior solo como una guía para las capacidades que necesita y para las validaciones. Use la "apariencia y sensación" de su nueva tecnología UI (WPF o lo que sea) para construir la interfaz de usuario y no intente una conversión mecánica. Acabarás persiguiendo píxeles y trabajando más de lo necesario si te mantienes demasiado cerca de la vieja interfaz de usuario. La aplicación anterior tenía 3 botones y una casilla de verificación. Genial, 3 botones de aspecto WPF y una casilla de verificación de aspecto WPF. ¿Cambia a una cinta mientras estás haciendo el cambio? Multa. Está bien verse diferente cuando termines.

A continuación, implementa sus bibliotecas nativas de lógica de negocios, compiladas como código nativo, su envoltorio C++/CLI, si tiene uno, y su interfaz de usuario administrada. Esto funcionará para cualquier cosa excepto el teléfono.

Solo tengo que volver a decir que NO porte su lógica empresarial C++ nativa en C# como parte de la fase inicial del proyecto. Cuando esté listo y funcionando, si tiene una buena razón comercial (como que ya no queremos gastar dinero en desarrolladores de C++), entonces puede considerarlo. Pero primero hazlo funcionar usando la interoperabilidad. Esto tiene la ventaja de que si su traducción arruina la delicada lógica de negocios escrita por personas que ya no están con usted, confiando en las sutilezas de C++ que su equipo actual desconoce, puede recurrir a las bibliotecas integradas por el resto de sus días.

4

He tenido una amplia experiencia en el pasado de migrar una gran aplicación de C++ (MFC) a C# (WinForms).

Algunos factores clave pueden afectar su estrategia:

  1. En primer lugar, ¿por qué tiene que migrar? Conozca sus objetivos para elegir una estrategia adecuada. En la mayoría de los casos, no debe migrar "solo" para que esté utilizando una tecnología nueva y atractiva.

  2. ¿Cuán grande es la base de códigos existente? Si se trata de una base de código muy pequeña que solo es cuestión de, digamos, semanas para reescribir, no se moleste en analizar demasiado y simplemente hágalo ...

  3. Tiene que convertir todas las funciones existentes a DO#? ¿O puede vivir manteniendo el C++ y solo agregando nuevas características en C#? Dependiendo de cómo se componetalice su código C++ existente, es posible que pueda usar tecnologías como COM Interop para continuar reutilizándola mientras desarrolla en C#.

  4. ¿Puede permitirse retrasar la publicación de una nueva versión hasta que vuelva a escribir todo? Usualmente la respuesta sería no. (Me viene a la mente Netscape, es posible que desee leer this ...) Es posible que desee crear una estrategia en la que pueda reemplazar gradualmente los componentes y los marcos en su aplicación, de forma que pueda liberar actualizaciones de la versión. , para que cada versión tenga un poco más de C# y un poco menos de C++.

  5. Básicamente, un enfoque que funcionó para mí fue reescribir los marcos básicos de mi aplicación en C#, y consumir esos marcos desde mi aplicación C++, utilizando COM Interop. Cada versión tenía algunos marcos y controles más en C#. Una vez que convertimos una masa crítica del código, así como todos los controles de nuestra ventana principal, cambiamos el punto de entrada de la aplicación para que sea .NET en lugar de C++.

  6. En cuanto a los recursos, para mí, el libro ".NET and COM: The complete interoperability guide" era un tesoro.

Eso es lo principal que se me ocurre en este momento. Es posible que pueda responder muchas preguntas más específicas que pueda tener.

+0

+20 si pudiera. Gran respuesta. –