¿Cómo funcionan las aplicaciones híbridas VB6 / .Net en el mundo real?

Mantengo una aplicación VB6 y estamos estudiando cómo migrar a .Net. Estamos considerando hacerlo gradualmente implementando nuevas características en las clases COM .Net visibles y migrando lentamente la funcionalidad existente. Encontré algunos ejemplos instructivos de 'Hello World' sobre cómo hacer esto y funciona bien con nuestra aplicación. Pero, ¿cómo es el comportamiento del mundo real de estas aplicaciones híbridas? ¿Son estables, mantenibles? Particular de nuestro programa es que más usuarios en la misma computadora lo usarán cambiando las cuentas de usuario.

EDITAR: la aplicación VB6 lee datos de una conexión USB y los almacena en una base de datos de Access. El usuario puede acceder a varias vistas de los datos. Los datos se almacenan en caché en un dispositivo de hardware, por lo que las interrupciones en la lectura no son fatales.

EDITAR 4 de octubre de 2015: Tiempo para un seguimiento: todavía estamos en el proceso de reemplazar el código VB6 existente paso a paso a .Net. Primero tomamos las rutinas de acceso a datos, luego la lógica de negocios y actualmente un formulario tras otro se convierte a WPF. De hecho, terminamos reescribiendo cada pieza de código que convertimos (en VB.Net), pero pudimos hacerlo lentamente y al mismo tiempo mejorar la funcionalidad. La aplicación híbrida sobrevivió a la transición a Windows 8, 8.1 y 10.

EDITAR el 9 de marzo de 2018: lanzaremos el código totalmente convertido el próximo mes. La aplicación híbrida será compatible durante al menos un año más. Muestra principalmente problemas en pantallas de alta resolución, pero de lo contrario funciona bien. Para ser honesto, tenemos más problemas de soporte debido a las instalaciones corruptas de .Net Framework y las instalaciones corruptas de dependencias (SQL Server LocalDb entre ellas) que los problemas de compatibilidad con la base de código VB6 ...

He tenido un éxito increíble exponiendo .NET a VB6 a través de interfaces COM. Al hacer esto, pudimos refactorizar inicialmente una gran cantidad de código VB6 y configurar una ruta de actualización a .NET. Solo tenga en cuenta que VB6 idiomático no se traduce bien a C # o incluso VB.NET, por lo que querrá pisar con cuidado.

El único problema que tuvimos que fue bastante molesto fue la cantidad excesiva de reconstrucciones que tuvimos que hacer debido a los cambios en la interfaz COM pública. Esto fue aliviado por Visual Make .

FWIW, en mi experiencia, la necesidad de actualizar una aplicación VB6 a .Net proporciona la excusa ideal para una reescritura. A menos que los codificadores originales fueran visionarios brillantes, las técnicas que prevalecen en VB6 rara vez se transfieren limpiamente a .Net.

Algunas de las delicias que encontrarás:

1. Terminarás con referencias a Microsoft.VisualBasic que realmente no quieres.
2. Serán errores difíciles de encontrar, por ejemplo, donde la subcadena VB6 (a, b, c) se representa silenciosamente como una subcadena (b, c) y explota en su cara porque estaba basada en 1 en VB6 y Basado en 0 en .Net.
3. Todas esas conversiones implícitas fáciles de codificar saldrán de la carpintería, generalmente en la primera PC que no tenga "," como delimitador de lista y / o "." como el separador decimal.
4. Sus clases convertidas no tendrán la ocultación de datos deseable que debería traer un rediseño.

HTH

Debería funcionar bien para usted, no hay nada en particular sobre el cambio rápido de usuario / sesiones múltiples que pueda causarle algún problema.

En términos de mantenibilidad, tenga en cuenta que el VB6 / VB.NET híbrido solo debería ser una solución temporal: su plan debería ser migrar completamente a VB.NET con el tiempo.