Cada vez que migras una línea de código de VB6 a .NET se muere un gatito en el mundo
Desde hace un corto espacio de tiempo a esta parte le he cogido gustillo al Twitter, y debo admitir que cada vez más.
He comprobado que esta herramienta no sólo se puede usar adecuadamente, sino que se puede usar de forma inadecuada hasta casi mantener un chat.
Eso es lo que ha pasado recientemente cuando algunos de las personas que me siguen en Twitter comenzamos a lanzar mensajes sobre migraciones de VB6 a .NET.
En este punto volvió a surgir la posibilidad de hacer un evento en MADNUG (el Grupo de Usuarios de .NET de Madrid) sobre este tema, algo sobre lo que ya estaba trabajando.
No obstante, surgieron interesantes comentarios al respecto y que me gustaría comentar.
Por un lado, hay muchísimas empresas hoy día que tienen productos Software desarrollados en VB6 (en la que actualmente trabajo sin ir más lejos).
También es cierto, que muchas empresas que tienen su Software desarrollado en VB6 creen que migrarlo a .NET es prácticamente automático (gran error).
Evidentemente, esas empresas no saben lo que son las pruebas unitarias ni tampoco consideran que aporten valor al Software (más que nada porque sus aplicacionesde VB6 adolecían de esto y funcionan “muy bien”).
Otras muchas piensan que al llamarse igual, ló único que varía es el “6” por “.NET”.
En muchos otros sitios, se piensa que Interop es la solución a todos los males.
Siguiendo con Interop, también hay muchas empresas o desarrolladores, que creen que Microsoft Windows Interop 2.1 es el aliado perfecto para continuar creciendo nuestro “engendro” creando un híbrido entre VB6 y .NET.
Incluso se piensa que ese híbrido entre VB6 y .NET es fácilmente mantenible y que Interop Forms Toolkit nos proporcionará más ventajas que una aplicación desarrollada únicamente con .NET.
Otras empresas migran y dejan la migración tal y como está (ADO, wrappers & Interop, etc).
Finalmente, otras piensan que todo eso está muy bien pero que es necesario empezar el desarrollo de cero.
Lo cierto es que cada uno tiene sus opiniones y experiencias, y lo que está claro es que no es lo mismo migrar una aplicación “simple” de VB6 a .NET, que una aplicación compleja.
Tampoco es directo el uso de controles de terceros y migrarlos por arte de magia a .NET.
También nos podemos encontrar con que determinadas propiedades de controles de VB6 no tienen su equivalente en .NET.
E incluso podríamos toparnos de bruces con objetos curiosos como VBA.Collection por citar uno con el que me he topado recientemente.
Son obstáculos, salvables muchísimos de ellos, pero muchos creen que no es necesario migrar, y ya no digamos empezar un desarrollo de cero desde VB6 a .NET.
Cierto es el dicho de si funciona no lo toques, pero cuidado con las cosas que no se tocan si quieres o tienes pensado abordar ciertos retos que hoy por hoy VB6 no te puede ofrecer (nuevas tecnologías, interoperabilidad, seguridad, etc).
Otro aspecto a tener en cuenta, es el soporte de VB6.
Por ahora vamos bien, porque utilizar un Software desarrollado en VB6 en sistemas operativos actuales (hasta Windows 7) es factible gracias al trabajo desempeñado por Microsoft para que así sea, sin embargo, la propia Microsoft no asegura que en un hipotético windows 8, VB6 continúe ejecutándose sin problemas como hasta ahora.
¿Qué hacer?. Muchos piensan que hasta que eso ocurra no nos debemos preocupar. De hecho, recientemente he ido a una administración pública en España y esta en concreto están llevando un concurso ahora para migrar sus Windows 2000 a Windows XP.
Se me ponen los pelos de punta con tan sólo pensarlo. No sé si será posible pasar ahora a un sistema operativo del año 2001, posiblemente no sea así y tenga que ser más actual, pero tener a finales del año 2010 un sistema operativo de hace 10 años da un poco de repelús, sinceramente (mi primer Linux lo instalé en el año 1996 y no se me ocurriría instalarlo hoy, me iría a la última versión o la más reciente posible).
Pero en este punto me he encontrado con otro problema (y cuento mi experiencia). Nuestro desarrollo de .NET es en .NET 4.0. Tenemos nuestra aplicación de VB6 y en este caso y por necesidades del guión, una pequeña utilidad que está desarrollada en .NET, sin embargo, y debido al soporte de windows 2000, nos vemos en la obligación de desarrollarla en .NET 2.0 para que se ejecute en Windows 2000 sin problemas.
Es decir, que para este caso concreto, el híbrido es más híbrido aún, teniendo una misma librería desarrollada en .NET 4.0 con LINQ (tal y como se había programado originalmente) y para este caso concreto, una “especial” en .NET 2.0.
Cuento esta pequeña experiencia porque todos y cada uno de nosotros tenemos la nuestra propia.
¿Migrar de VB6 a .NET?, ¿empezar el desarrollo completo de cero de VB6 a .NET?, ¿pasar bloques o partes de VB6 a .NET poco a poco?, ¿pros?, ¿contras?, ¿acceso a datos?, ¿apis?, ¿controles personalizados?, ¿controles de terceros?, ¿recursos?, ¿multidioma?, ¿seguridad?,… etc.
Ernesto por su parte, nos invitó a acceder y leer una entrada que él mismo ha publicado recientemente sobre este tema, entrada que conviene leer por tener sus particulares puntos de vista (la experiencia de todos es la que nos da una visión más enriquecedora).
Si se lleva a cabo el evento en MADNUG de migración de Software de VB6 a .NET, promete ser muy entretenido y dispar.
No obstante, si te atreves y te ves con ganas y fuerzas, me gustaría que indicaras aquí tu experiencia para nos enriquezcamos todos.
Es muy interesante que hablemos de estas cosas sin ningún tipo de rubor, digamos lo que pensamos y quizás nos animemos a tomar el toro por cuernos sin miedo a ser cogidos.
Cada vez que se migra una línea de código de VB6 a .NET no se muere ningún gatito en el mundo. Creo que en esto hay mucho temor, mucho más del que muchos admiten públicamente, y muchas empresas no se atreven aún en dar el salto a .NET porque temen que algún gatito fallezca por el camino.
P.D.: Y ya no hablo de migraciones de FoxPro a .NET porque esto es ya para nota.
Un saludo.
21 Responsesso far
Pues ya sabes que cuentas conmigo para la mesa redonda … VB6 es una de mis escuelas y la verdad es que hay mucho para comentar al respecto ^^
Salu2
¡Por supuesto!
Muchas gracias Bruno.
Podemos ir preparando ya el evento. 😉
Yo no veo que se pueda llamar migración. Como sabemos, realmente deberían de desarrollar una aplicación nueva desde cero.
¿no sería recomendable aprovechar para volver a analizar y mejorar el producto?
¿Ve? Yo no tengo ese problema.
Nunca he migrado una línea de VB6 a .NET… ni ya de paso escrito siquiera una. 🙂
Muchas gracias por comentar Alberto y Rafael.
@Alberto, no es migración y sí lo es. En Visual Studio hay una herramienta (creo recordar que en VS 2010 ya no está disponible) que migra un proyecto de VB6 a .NET. Arregla unas cuantas cosas y otras las deja para que las arregles tú.
Sin embargo, apuntas una cosa que aplaudo a más no poder, la posibilidad de aprovechar el momento para analizar y mejorar el producto.
Interesante tema para debatir, porque a lo mejor es bueno adaptar el Software de acuerdo a los requerimientos, pero no todas las empresas tienen los recursos económicos ni el personal cualificado o preparado para llevar a cabo esta tarea.
Es interesante, muy interesante lo que apuntas, pero ¿es realmente viable?.
@Rafael, ¡suerte que has tenido!. Te envidio, aunque pasar una línea de código de VB6 a .NET es muy interesante, se convierte incluso a veces en un reto. 🙂
¿Y qué podemos decir de la siguiente cuestión?
¿Y si tenemos que migrar nuestra aplicación de VB6 a C#? Creo que ahí si estaríamos ante la tesitura de analizar y mejorar el producto o pasar por una doble conversión con lo que podría haber una pérdida de código asociada.
VB6 <> VB.NET
VB.NET <> C#
Saludos.
Fran
@Fran, personalmente si el paso se va a realizar de VB6 a C#, yo sin pensarlo, lo haria directemante, porque pasarlo primero a VB .NET y luego a C# sería realizar, casi un proyecto nuevo en VB.NET, y luego una migración.
Hablamos de migraciones a .NET, concretamente a VB.NET, porque el desarrollador de VB6 se puede sentir mas cómodo a la hora de codificar, porque todavía existen cosas que funcionan en VB.NET provenientes de VB6, sin embargo, si pasamos a C# para que dichas funcionalides “funcionen”, valga la redundancia, sería necesario exportar el namespace VisualBasic…
Soy muy PRO VB.NET, pero algo que si que considero que ayudaria a un desarrollador de VB6 a conocer mejor el FrameWork, sería empezar con C#, para tener un cambio de forma de pensar.
Saludos.
Y con lo que mola el VB6!! Cuántas horas, jajaja, y qué recuerdos!
Pero si las migraciones molan! Ahora estoy trabajando en una de Power Builder a Asp.net, o sea de una plataforma de escritorio a un entorno cliente-servidor. Menudo reto!!
Una de las conclusiones que he sacado, es que el momento de la migración, es momento de reanálisis. En mi caso creo que habría supuesto un ahorro de costes. Básicamente por que la aplicación tiene la tira de años, y un montón de funciones que ya nadie recuerda para qué servían. Y las hemos tenido que migrar de todos modos. Un reanálisis, viendo qué es imprescindible, en el que se fueran migrado funciones de a poco, habría supuesto sin duda un ahorro.
Totalmente de acuerdo contigo.
Un buen conocimiento del .NET Framework ayudará a realizar una mejor migración y llegado el caso a readaptar toda la aplicación, pero como mencionaba Jorge todo ello requiere de personal y recursos varios.
Saludos.
Fran
Viable o no viable el re-análisis y las mejoras tienes que llegar.
Aunque sea en forma de UX o de rendimiento del código.
La migración automática no era muy buen y poco recomendable cuando utilizas OCX (cosa que era muy habitual en vb6)
Sinceramente, antes de pensar en migrar una aplicación de Vb6 a .NEt, pensaría primero en realizar un proyecto nuevo (a ser posible pequeño) que entre a tu empresa, en Vb.Net y cuando te sientas suelto, pensar en migrar la aplicación. Por supuesto en .Net partir con alguna Suite de controles de terceros.
nadie llorará unos miserables gatitos…
deberiamos mirar aver si de alguna forma pudieramos diseñar algun programa para hacerlo compatible…eso seria genial asi de un plumazo seguiriamos en Vb6 en los nuevos Windows…Esto va a afectar a millones de empresas que tienen programas de arquitectura Vb6.
Pues yo tengo experiencia en .Net, y eso definitivamente es muy necesario si se quiere acometer una migracion, el problema es cuando te falta la otra parte, el conocimiento de lo que hacia internamente la aplicación a migrar.
Cuenta conmigo para lo de la sesion, en este momento estoy probando tres herramientas de apoyo que vienen a ayudar mucho en el workflow que estoy pensando para una migración efectiva.
Como dije en mi post, en un momento Microsoft decidio romper la compatibilidad de manera radical, haciendo un gap muy grande, pues los cambios son en dos areas: lenguaje y framework (COM/.NET), siendo que el primero es el que da mas problemas por los comportamientos que esperabas en algunas acciones.
Yo tampoco voy a hablar de migraciones de RM/Cobol 85 a C#.NET porque tambien son palabras mayores. 🙂
Me lo tomo como hobby ..
Aquí va la segunda parte de mis reflexiones acerca de una migración…. si se decide que ese es el camino.
http://www.consultorinternet.com/2010/10/pensando-en-estrategias-de-migracion-de.html
Espero sus comentarios 🙂
La verdad es que todo esto es muy entretenido, yo paso de migraciones, loq ue estoy haciendo es pasando el código poco a poco y como puedo, de otra manera en lo que se refiere acceso a datos, no pasando a NET PURO estás bien jodido, de tomas maneras bien jo… estamos.
un saludo a todos, y aquí estoy para lo que querais.
Jesús
Con visual basic 6 hacemos y hemos hecho auténticas virguerías. Y si las hemos hecho se debe a que no era nada complicado el programar con éste maravilloso lenguaje.
Formularios, funciones y módulos.
Bueno, también estaban algunos más atrevidos creando ocx, dll’s. Que por cierto me hace gracia lo de crear dll’s ya que con visual basic 6 había unos pocos que creían saber programar dll’s y eso es un poco discutible.
Para mi, una dll que chute, y bien, como mínimo debe de tener 200 líneas de código y a ver que código.
Para meter menos líneas en una dll para eso te creas una simple function y arreando.
A bacilar a la cibeles!! jeje
Ahora que pasa, pues que viene el Visual Basic.NET. Bueno eso de que viene lleva viniendo desde el año 2002.
De programar en vb6 a vb.net sigue siendo programar. Hasta ahí deacuerdo, pero viene con un regalito llamado framework.
Sálvese quien pueda.
Quien diga, crea o piense que sabe programar con visual basic.net está diciendo que conoce framework. Y conocer framework es saber de dónde cuelga lo que hace que tu código funcione. Sí o sí?
Me escojono cuando veo ofertas donde pone
programadores en .net
sería tan amable de explicarme que lenguaje es el que requiere ese puesto de trabajo? gracias!!
Mas que nada porque hay C#, Visual Basic, Delphi (Object Pascal), C++, J#, Perl, Python, Fortran, Prolog (existen al menos dos implementaciones, el P#[1] y el Prolog.NET[2] ), Cobol y PowerBuilder.
Claro, lo mejor es pensar que la persona que pone el anuncio no tiene porque saber de tecnologías. Me parece correcto pero a la persona que pone el anuncio alguien le pasará lo que requiere el puesto de la oferta no?
Jamás existirá un experto en .NET al igual que en JAVA.
Visual basic.NET no es visual basic.
Saludos !!
Migra una aplicacion, es como una matrimonio, es un evento importante, que debe considerar compromiso, pero para adoptar el compromiso debes conocer los pro y los contra, segun mi experiencia antes de migrar una aplicacion debes tener en cuenta si vale la pena el cambio, asi de simple
Al final si hay diferencias considerables desde VB6 a VB.NET. Yo recomiendo comprender la lógica y recrear de 0 en VB.NET.
Es bien complejo el tema. Si no tienes tiempo…hay que migrar con Interop o como puedas. Si tienes tiempo y recursos, directamente reescribe todo en .NET Es mas robusto y será mantenible por más tiempo.