Como os aplicativos híbridos VB6 / .Net estão funcionando no mundo real?

Estou mantendo um aplicativo VB6 e estamos estudando como migrar para .Net. Estamos considerando fazer isso gradualmente implementando novos recursos nas classes .Net visíveis COM e migrando lentamente a funcionalidade existente. Encontrei alguns exemplos instrutivos do 'Hello World' sobre como fazer isso e funciona bem com nosso aplicativo. Mas como é o comportamento do mundo real desses aplicativos híbridos? Eles são estáveis, sustentáveis? Particular do nosso programa é que mais usuários no mesmo computador o usarão alternando as contas de usuário.

EDIT: O aplicativo VB6 lê dados de uma conexão USB e os armazena em um banco de dados do Access. O usuário pode acessar várias visualizações dos dados. Os dados são armazenados em cache em um dispositivo de hardware, portanto, as interrupções na leitura deles não são fatais.

EDITAR 4 de outubro de 2015: Hora do acompanhamento: Ainda estamos no processo de substituir o código VB6 existente passo a passo para .Net. Primeiro, adotamos as rotinas de acesso a dados, depois a lógica de negócios e atualmente um formulário após o outro é convertido em WPF. Acabamos reescrevendo todos os trechos de código que convertemos (no VB.Net), mas conseguimos fazê-lo lentamente e, ao mesmo tempo, melhorando a funcionalidade. O aplicativo híbrido sobreviveu à transição para o Windows 8, 8.1 e 10.

EDITAR 9 de março de 2018: lançaremos o código totalmente convertido no próximo mês. O aplicativo híbrido será suportado por pelo menos um ano. Está mostrando principalmente problemas em telas de alta resolução, mas funcionando bem de outra forma. Para ser sincero, temos mais dores de cabeça de suporte devido a instalações corrompidas do .Net Framework e instalações corrompidas de dependências (entre elas o SQL Server LocalDb) do que problemas de compatibilidade com a base de código do VB6 ...

Tive um sucesso incrível ao expor o .NET ao VB6 por meio de interfaces COM. Ao fazer isso, conseguimos refatorar inicialmente uma enorme quantidade de código VB6 e configurar um caminho de atualização para o .NET. Lembre-se de que o VB6 idiomático não se traduz bem em C # ou mesmo no VB.NET, portanto, você deve agir com cuidado.

O único problema que tivemos e que foi bastante irritante foi a quantidade excessiva de reconstruções que tivemos que fazer devido a alterações na interface COM pública. Isso foi aliviado pelo Visual Make .

FWIW, na minha experiência, a necessidade de atualizar um aplicativo VB6 para .Net fornece a desculpa ideal para uma reescrita. A menos que os codificadores originais fossem visionários brilhantes, as técnicas predominantes no VB6 raramente são portadas de maneira limpa para .Net.

Algumas das delícias que você encontrará:

1. Você terminará com referências ao Microsoft.VisualBasic que você realmente não deseja.
2. Eles serão difíceis de encontrar erros, por exemplo, onde a substring do VB6 (a, b, c) é processada silenciosamente como a.SubString (b, c) e explode na sua cara porque era baseada em 1 no VB6 e Baseado em 0 em .Net.
3. Todas essas conversões implícitas fáceis de codificar sairão da madeira, geralmente no primeiro PC que não possui "," como o delimitador da lista e / ou "." como o separador decimal.
4. Suas classes convertidas não terão a ocultação de dados desejável que um novo design deve trazer.

HTH

Deve funcionar bem para você, não há nada em particular na troca rápida de usuário / várias sessões que devem causar problemas.

Em termos de manutenção, lembre-se de que o VB6 / VB.NET híbrido deve ser apenas uma solução temporária: seu plano deve ser migrar completamente para o VB.NET ao longo do tempo.