Migración de una aplicación Delphi 7 a .NET

Question

¿Algún consejo sobre cómo migrar una aplicación comercial existente de Delphi 7 a .NET 2.0 en Visual Studio 2005?

Visual Studio 2005 ya se ha comprado, la empresa quiere alejarse de las herramientas de Borland/Codegear.

La aplicación es un solo servidor ejecutable del cliente, que utiliza una serie de controles de interfaz de usuario de terceros y Crystal Reports 10 para informar.

Existe una amplia lógica de negocios repartida entre los tipos de Delphi en la interfaz de usuario, así como en muchos procedimientos almacenados de SQL Server 2000. Mover gran parte de la lógica de proceso almacenada en clases .NET es otro objetivo.

Para reducir el impacto en los clientes, se preferiría un enfoque pieza por pieza en lugar de una reescritura/conversión completa, si es posible. Gracias por adelantado.

[Actualizar] ¿Alguien ha tenido alguna experiencia, buena, mala o fea, utilizando Managed VCL para este tipo de escenario?

Answer 1

Trabajé en una empresa que estaba migrando de Delphi a WPF/.Net alrededor del año 2007. Intentamos un enfoque pieza por pieza. Fue doloroso. Siempre nos encontramos con errores sutiles en la interoperabilidad. Llamar desde Delphi a WPF o Winforms y viceversa es doloroso. Si los diversos controles de la interfaz de usuario y las ventanas de su aplicación se convocan mucho entre sí, creo que experimentará importantes dolores de crecimiento.

Si puede permitirse hacer toda la conversión de inmediato, lo conseguiría. De lo contrario, divida las partes de su aplicación que son independientes o tienen el mínimo de interacciones con el resto de la aplicación.

También me gustaría sugerir entrar en .Net 2008. ¿Por qué elige una tecnología que tiene casi 4 años (VS 2005)? Creo que tomar una decisión comercial muy, muy mala es optar por .Net 2.0 cuando .Net 3.5 es muy estable. La única razón válida que alguna vez presentaría a la administración de .Net 2.0 sería que sea compatible con Windows 2000. ¿Todavía tiene clientes en Win2k?¿Todavía tendrá clientes en Win2k cuando se complete su conversión? ¿Tiene clientes a los que no puede trasladarse a XP o Vista? .Net 3.0 y 3.5 no son compatibles con Win2k. Esa es la única desventaja que puedo pensar.

.Net 3.5 y C# 2008 ofrecen ventajas significativas para su empresa. Tiene una serie de funciones de lenguaje que acelerarán el desarrollo en comparación con C# 2.0. Tienes WPF, que es muy superior a Winforms. Yo diría que puede desarrollar el mismo Windows gris de batería que obtendría en Winforms con WPF, desarrollarlo más rápido, y cuando quiera algo llamativo, usará una tecnología que puede proporcionarlo fácilmente. Si está aprendiendo una nueva plataforma de ventanas para esta conversión, ¿por qué no invertir en aprender cosas nuevas?

Además, dígame que en realidad no compró VS 2005. Puede comprar una licencia MSDN Universal por el mismo costo y obtener todos los productos relacionados con el desarrollo que Microsoft hace. Cómprelo a un tercero y obtendrá un buen descuento.

Lo siento si salí negativo. Atentamente, buena suerte en la migración. Acabo de tener flashbacks cuando pienso en tener que renunciar a todas las cosas buenas en .Net 3.5.

Answer 2

Una conversión gradual significaría cambiar el código de Delphi nativo de utilizar COM para el lado .NET puede coexistir con Delphi (o posiblemente mediante alguna otra tecnología - difícil de decir)

Si es posible, podría será más fácil convertir la aplicación a Delphi.NET primero, luego al menos los bits .NET podrán comunicarse un poco más fácilmente.

Solo un pensamiento.

Answer 3

Solo usted realmente puede decidir si es posible un acercamiento pieza por pieza. Por ejemplo, la aplicación puede dividirse fácilmente o todas las formas están muy unidas con toda la lógica comercial. Técnicamente es posible, pero todo depende de cómo esté realmente estructurada la base del código.

Answer 4

Eso me suena a really bad idea.

¿Existe alguna ventaja tecnológica para su producto en .NET, o es principalmente una decisión política ser una tienda de Microsoft? Para el cliente-servidor, Delphi es bastante difícil de superar. Utilicé VS2005/8 y realmente y sinceramente no es tan bueno como Delphi para el desarrollo de Win32. Pero si vas a migrar a la web más adelante, entonces VS tiene ventajas definitivas.

Si la gente de negocios obstinada simplemente se niega a usar Delphi nunca más, entonces KiwiBastard es correcto, IMO. Convierta primero a Delphi.NET, luego migre desde allí a VS2005. O 2010, ya que es una línea de tiempo más realista :)

Answer 5

Para mí la pregunta sería: ¿qué idioma estarías usando? Espero C# y no VB.Net. (Con toda la política incómoda en este caso de uso esto no está claro de ninguna manera.)

Lo siguiente que probablemente escuche es que hay conversores que lo ayudarán a hacer esto. Acabamos de pasar por una evaluación de dichos convertidores (Delphi 7 a C#) y estábamos muy contentos. decepcionado.

¿Puedo sugerir un compromiso? ¿Qué hay de Delphi Prism? Es Delphi en VS2008. Claro, todavía tienes Delphi y, por lo tanto, Codegear, pero también tienes VS (como tu empresa espera que lo hagas).

Answer 6

Trabajé anteriormente en una empresa que quería convertir de Delphi a C# .NET porque .NET es todo genial y brillante. Trajeron algunos desarrolladores más que tenían mucha experiencia en C# y terminaron teniendo 3 veces más tiempo para que los desarrolladores transfirieran la aplicación a C# y luego escribieron la primera vez en Delphi con muy poco ROI adicional (unos pocos nuevas características fueron agregadas en el proceso). Además, los clientes no estaban contentos con el rendimiento de la aplicación o la interfaz de usuario.

Caso práctico después del estudio de caso muestra que rewriting is a bad idea. (Sombrero de punta a kogus)

Si tiene que mover a .NET (sí, lo sé, no se tomó la decisión, alguien con menos información DID) a continuación, se recomienda usar Delphi for .NET o RemObjects Oxygene. Este último es un complemento de Visual Studio. Pero incluso marc hofman, the Chief Software Architect of RemObjects Oxygene ha dicho que es una mala idea migrar una aplicación que funciona perfectamente a .NET "solo porque".

Si puede esperar a Delphi Prism, que también es un complemento de Visual Studio y se espera que salga a finales de este año.

Answer 7

Alejarse de las herramientas de CodeGear/Borland básicamente elimina cualquier solución basada en Delphi .NET y una reescritura total de su aplicación.

Espero que mi respuesta a continuación ayude con sus decisiones.

Por experiencia (haber reescrito una aplicación Delphi con un equipo de personas) se reduce a cualquiera de las siguientes dos opciones.

Pero primero una advertencia: tomará al menos el esfuerzo total de desarrollo que tomó escribir su aplicación actual de Delphi.

En nuestro caso, este esfuerzo estaba garantizado ya que la antigua aplicación Delphi (que de hecho era Kylix) tenía un fin de vida debido a varias razones. Nuestra reescritura consistió en dos partes: reescribir con funcionalidad extra limitada seguida de mucha funcionalidad adicional (el diseño de la primera parte ya tenía en cuenta la segunda parte).

Volver a las opciones:

1- una reescritura total en el C# o VB.NET en Visual Studio

2- una reutilización parcial de su código de capa de negocio de Delphi existentes mediante el uso de Oxygene RemObjecs (una Complemento de Visual Studio con una sintaxis muy similar a la sintaxis de Delphi). CodeGear ofrecerá Prism pronto (probablemente antes de finales de 2008), que también se integrará en Visual Studio.

Dado que el acceso a datos .NET y la interfaz de usuario son totalmente diferentes de Delphi, tendrá que hacer esto desde cero (tanto para el escenario 1 como para el 2). Visual Studio 2008 ofrece muchos beneficios aquí en Visual Studio 2005.

No hay tal migración gradual, ya que aquí se hace un cambio completo de la plataforma, se trata de un todo o nada.

Ambos escenarios llevarán un tiempo considerable (aunque tengas experiencia en Delphi, acostumbrarte al mundo .NET llevará tiempo).

Visual Studio puede interactuar con Crystal Reports y funciona bien con SQL Server.

Dado que Visual Studio 2008 ofrece muchos beneficios (no solo .NET 3.5, sino también productividad), será mejor que lo haga. En el lado de la interfaz de usuario, debe hacer una elección equilibrada entre WinForms (también conocido como Windows Forms) y Windows Presentation Foundation (también conocido como WPF).

Si se trata de una reescritura 1-a-1, es posible que desee seguir con WinForms, ya que es familiar a lo que tiene. Probablemente necesites utilizar algunos componentes de terceros para poner en marcha tu UI; DevExpress es una buena opción, ya que tienen componentes similares en Delphi y Visual Studio.

Pero si quieres ir para el futuro, entonces podrías considerar WPF. Prepárese para una curva de aprendizaje más empinada aquí que WinForms ya que es muy diferente de lo que está acostumbrado.

Si decide quedarse con Delphi, es posible que desee buscar en VCL para la Web (también conocido como IntraWeb) y en Delphi 2009 (mucho ha cambiado en el mundo Delphi desde que se anunció Delphi 7 hace 6 años).

¡Buena suerte al elegir!

--jeroen

Answer 8

Yo sugeriría mirar Hydra de RemObjects. Básicamente rapea la interfaz com para usted y proporciona un patrón de observador para la interfaz entre su aplicación Delphi y .Net. Puede hacer que los formularios .Net aparezcan en los paneles dentro de su aplicación Delphi. Esto proporciona una buena ruta de migración en la que reemplaza su código Delphi poco a poco a medida que migra la funcionalidad a .Net.

Answer 9

Ha habido un informe científico de una transformación exitosa de un Proyecto Delphi de 1,5 millones de líneas a C# por John Brant, Don Roberts et al.Escribió un analizador Delphi, un generador de C# y muchas reglas de transformación en el AST. Gradualmente extendiendo el conjunto de reglas, haciendo una compilación diaria, muchas pruebas de unidad, y reescribiendo partes difíciles de Delphi le permitieron con un equipo de 4, entre los cuales algunos de los desarrolladores originales, con profundos conocimientos de Delphi & C#, migrar el software en 18 meses. John Brant & Don Roberts siendo los desarrolladores originales del navegador de refactorización y el kit de construcción del compilador SmaCC, es poco probable que pueda ir tan rápido.

Aunque esta fue una inversión significativa, no es en ninguna parte "del mismo tamaño que el desarrollo original". Los autores señalan que una reescritura directa, sin herramientas o con una herramienta de un solo disparo, como señaló Jeroen, es muy probable que resulte en eso, especialmente si se tienen en cuenta nuevos requisitos.

Los autores han realizado refactorizaciones a gran escala mientras permanecían en la misma plataforma para un proyecto diferente, reemplazando por completo la infraestructura de persistencia. Esto podría ser relevante para proyectos antiguos (BDE?).