Mejor estrategia para pasar de VB6 a .NET

Question

Mi empresa tiene un montón de aplicaciones heredadas que están escritas en VB6.

Estamos en transición de mover aplicaciones VB6 a .NET (3.5 específicamente).

¿Cuál sería la mejor estrategia para mover el formulario VB6 a .NET?

NOTA: Por debajo de actualización debe ir a "Gestión de Proyectos" y no tiene nada que ver con la cuestión principal.

[ACTUALIZACIÓN]: Gracias por su respuesta que hasta ahora
Ahora hay pregunta más que pop-up son

1. ¿cómo se le asignará a los desarrolladores crear nuevas aplicaciones?
2. ¿Debería haber una división especial de actualización única que convierta las aplicaciones antiguas en nuevas? ¿O debería cada desarrollador participar en el proceso de conversión ?
3. ¿Solo los desarrolladores senior deberían participar en la conversión? Junior desarrolladores? o mezclado?

Parece que, cuanto más pienso en este problema, más preguntas simplemente muestran arriba.

Answer 1

Claramente esta es una empresa importante que requerirá mucho trabajo.
Así que mi consejo sería tratarlo como un proyecto a muy largo plazo.

Tenga un objetivo claro en mente, que resuelva problemas importantes como la seguridad, la capacidad de recuperación, la capacidad de mantenimiento y el futuro de sus aplicaciones.

Una vez que esto haya sido acordado por los interesados, desarrolle un prototipo de sistema para probar sus suposiciones con, donde puede probar C# vrs VB.net o MVC vrs Webforms. Asignaría a tus mejores desarrolladores para esto.

Luego, comience con uno de sus pequeños sistemas heredados y construya los componentes principales que va a reutilizar en otras áreas.
En esta etapa, comience con sus desarrolladores más experimentados, pero todos deben involucrarse y estar familiarizados con el nuevo marco.
Esto asegurará que todos estén entrenados al mismo tiempo y que nadie quede atrás.
Dependiendo de la cantidad de aplicaciones que tenga, rotaré a los desarrolladores para que todos los sistemas puedan beneficiarse.

También todos los trabajos nuevos deben realizarse en su idioma .net no en VB6.

Convierta gradualmente cada una de sus aplicaciones heredadas. (Solo los convertiría si están cambiando o si hay un claro beneficio de actualizarlos.)

Esto debería proporcionarle un marco sólido para usar en el futuro, al tiempo que garantiza que la funcionalidad de los usuarios no se vea obstaculizada por su migración.

Por ejemplo:
He trabajado en una empresa que tenía aproximadamente 40 aplicaciones de VB.
Con el tiempo hemos migrado todos estos a C# y ahora (5 años después), tenemos aproximadamente 150 aplicaciones C# (todo en .net 2.).

Todos estos comparten un marco común, por lo que son fáciles de mantener y ampliar cuando sea necesario.

Answer 2

Me gustaría empezar con las herramientas de Microsoft:

http://msdn.microsoft.com/en-us/library/aa480541.aspx

Answer 3

ver esto:
https://stackoverflow.com/questions/507291/should-we-select-vb-net-or-c-when-upgrading-our-legacy-apps

Por supuesto, C# y VB.Net es sólo una parte de ella.

Por ejemplo, otra cosa a considerar es si desea utilizar esta oportunidad para mover estas aplicaciones a una intranet, si no lo ha hecho aún. O qué tan profundo quieres profundizar en la pila de microsoft. ¿Es suficiente Winforms o quieres usar WPF, por ejemplo?

Answer 4

Usted puede encontrar el siguiente artículo útil: http://www.vsj.co.uk/articles/display.asp?id=756

Answer 5

intente reemplazar la funcionalidad básica con COM habilitado .NET bibliotecas. "Ahueque" sus aplicaciones VB6 existentes moviendo la funcionalidad a .NET poco a poco.

Tenga cuidado con las reescrituras completas. Aunque son tentadores "porque es un corte limpio", generalmente la locura está por venir. Lea "Trabajar eficazmente con código heredado" de Michael Feathers como preparación. Aunque el libro no trata específicamente de "pasar de un idioma a otro", sí muestra muchos escollos del mundo real que encontrará.

Creo que todos los desarrolladores deberían tener ranuras de tiempo definidas en las que migren en las aplicaciones heredadas que desarrollaron anteriormente. Como ya tienen conocimiento de dominio y conocen el espacio problemático, deberían ser los más productivos.

Answer 6

Aquí hay una adaptación de mi answer a una pregunta similar.

La conversión automática de programas grandes es una mejor opción que la reescritura. Es un error común comenzar de manera optimista la reescritura de una gran pieza de software, realizar buenos progresos iniciales para corregir algunos de los defectos conocidos de la arquitectura anterior y luego empantanarse en la funcionalidad que acaba de dar por sentada. años. En este punto, su gestión comienza a ponerse nerviosa y todo puede ser muy incómodo.

... y aquí es un blog por un Microsofty que agrees with me:

Muchas compañías con las que trabajé en los primeros días de .NET miraron por primera vez en la reescritura impulsado en parte por un fuerte deseo de mejorar la arquitectura subyacente y estructuras de código al mismo tiempo que se movieron a .NET. Lamentablemente, muchos de esos proyectos se encontraron con dificultades y varios nunca se completaron.El problema que estaban tratando de resolver era demasiado grande

Este excelente page Microsoft recomienda dos herramientas de migración tercer partido como mejor que el asistente de poca potencia incorporado en VB.NET - Artinsoft actualizar y CodeArchitects VBMigration. Artinsoft escribió el asistente de actualización incorporado de VB.NET, esta es su versión mejorada. Y CodeArchitects fue fundada por Francesco Balena, quien escribió algunos de los classic books en VB6 y VB.NET.

La misma página Microsoft también dice:

Realización de una reescritura completa de .NET es mucho más costoso y difícil de hacer bien [que convertir] ... que sólo recomendaría este enfoque para un número pequeño de situaciones

---

EDIT: Sung dice en los comentarios: "No soy un gran fan de la generación automática de código porque es más difícil de depurar al principio y podría tomar el mismo tiempo que se tarda en volver a escribir todo el asunto" . Tengo que estar muy en desacuerdo. En general, yo tampoco soy partidario de la generación de código, pero en este caso el código resultante se estructurará de manera idéntica a su VB6 original y debería ser casi totalmente funcional. Todavía no he probado estas herramientas, pero desde su customertestimonials esta promesa se cumple.

Y repito el consejo Microsoft justo por encima, sobre la base de su experiencia de ayudar a muchas migraciones - "una reescritura completa es mucho más costoso y difícil de convertir [el énfasis es mío]" - una contradicción plana de la suposición de que se podría tomar el mismo tiempo. Si desea mejorar la estructura del VB6, la migración y la refactorización gradual probablemente sean mucho más rentables que una reescritura.