Come funzionano le applicazioni ibride VB6 / .Net nel mondo reale?

Sto mantenendo un'applicazione VB6 e stiamo studiando come migrare a .Net Stiamo valutando di farlo gradualmente implementando nuove funzionalità nelle classi .Net visibili COM e migrando lentamente le funzionalità esistenti. Ho trovato alcuni esempi istruttivi di "Hello World" su come eseguire questa operazione e funziona perfettamente con la nostra app. Ma come è il comportamento nel mondo reale di queste applicazioni ibride? Sono stabili, mantenibili? Particolare del nostro programma è che più utenti sullo stesso computer lo useranno cambiando account utente.

EDIT: l'app VB6 legge i dati da una connessione USB e li memorizza in un database di Access. L'utente può richiamare varie viste sui dati. I dati vengono memorizzati nella cache di un dispositivo hardware, quindi le interruzioni nella lettura non sono fatali.

EDIT 4 ott 2015: tempo per un follow-up: stiamo ancora sostituendo il codice VB6 esistente passo dopo passo a .Net. Per prima cosa abbiamo assunto le routine di accesso ai dati, quindi la logica di bussiness e attualmente un modulo dopo l'altro viene convertito in WPF. Alla fine abbiamo riscritto ogni pezzo di codice che abbiamo convertito (in VB.Net), ma potevamo farlo lentamente e allo stesso tempo migliorando la funzionalità. L'applicazione ibrida è sopravvissuta alla transizione a Windows 8, 8.1 e 10.

EDIT 9 marzo 2018: rilasceremo il codice completamente convertito il prossimo mese. L'applicazione ibrida sarà supportata per almeno un anno in più. Sta mostrando principalmente problemi su schermi ad alta risoluzione, ma altrimenti funziona bene. Ad essere onesti, abbiamo più mal di testa di supporto a causa di installazioni di .Net Framework corrotte e installazioni di dipendenze corrotte (tra cui SQL Server LocalDb) rispetto a problemi di compatibilità con la base di codice VB6 ...

Ho avuto un successo incredibile esponendo .NET a VB6 tramite interfacce COM. In questo modo siamo stati inizialmente in grado di effettuare il refactoring di un'enorme quantità di codice VB6 e impostare un percorso di aggiornamento a .NET. Tieni a mente che VB6 idiomatico non si traduce bene in C # o anche in VB.NET, quindi ti consigliamo di procedere con cautela.

L'unico problema che è stato piuttosto fastidioso è stato l'eccessiva quantità di ricostruzioni che abbiamo dovuto fare a causa delle modifiche all'interfaccia COM pubblica. Ciò è stato alleviato da Visual Make .

FWIW, nella mia esperienza la necessità di aggiornare un'app VB6 a .Net offre la scusa ideale per una riscrittura. A meno che i programmatori originali non fossero visionari brillanti, le tecniche prevalenti in VB6 raramente vengono portate in modo pulito su .Net.

Alcune delle delizie che incontrerai:

1. Finirai con riferimenti a Microsoft.VisualBasic che non vuoi davvero.
2. Saranno bug difficili da trovare, ad esempio dove la sottostringa VB6 (a, b, c) viene visualizzata in modo silenzioso come a.SubString (b, c) e esplode in faccia perché era basata su 1 in VB6 e Basato su 0 in .Net.
3. Tutte quelle conversioni implicite facili da codificare verranno fuori dalla struttura, di solito sul primo PC che non ha "," come delimitatore di elenco e / o "." come separatore decimale.
4. Le tue classi convertite non avranno il desiderabile nascondiglio di dati che dovrebbe portare una riprogettazione.

HTH

Dovrebbe funzionare bene per te, non c'è nulla in particolare sulla commutazione rapida dell'utente / sessioni multiple che potrebbe causare problemi.

In termini di manutenibilità, tieni presente che l'ibrido VB6 / VB.NET dovrebbe essere solo una soluzione temporanea: il tuo piano dovrebbe essere quello di migrare completamente su VB.NET nel tempo.