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

11

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

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

EDIT 4 ottobre 2015: Tempo per un follow-up: stiamo ancora sostituendo il codice VB6 esistente passo dopo passo a .Net. Per prima cosa abbiamo adottato le routine di accesso ai dati, quindi la logica di bussiness e attualmente una forma dopo l'altra viene convertita in WPF. Abbiamo infatti finito per riscrivere ogni pezzo di codice che abbiamo convertito (in VB.Net), ma potevamo farlo lentamente e allo stesso tempo migliorare 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ù. Mostra principalmente problemi su schermi ad alta risoluzione, ma funziona bene altrimenti. Per essere onesti, abbiamo più mal di testa a causa di installazioni .Net Framework corrotte e installazioni di dipendenze corrotte (SQL Server LocalDb tra loro) rispetto a problemi di compatibilità con la base di codice VB6 ...

    
posta Dabblernl 24.01.2011 - 11:57
fonte

3 risposte

5

Ho avuto un successo sorprendente esponendo .NET a VB6 tramite interfacce COM. In questo modo siamo stati in grado di ridefinire inizialmente una grande quantità di codice VB6 e impostare un percorso di aggiornamento a .NET. Ricorda che l'idioma VB6 non si traduce bene in C # o persino in VB.NET, quindi dovrai procedere con cautela.

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

    
risposta data 24.01.2011 - 14:24
fonte
6

FWIW, nella mia esperienza la necessità di aggiornare un'app VB6 su .Net fornisce la scusa ideale per una riscrittura. A meno che i codificatori originali non siano stati dei visionari brillanti, le tecniche prevalenti in VB6 raramente hanno una porta pulita su .Net.

Alcune delle delizie che incontrerai:

  1. Finirai con riferimenti a Microsoft.VisualBasic che davvero non vuoi.
  2. Saranno bug difficili da trovare, per esempio dove la sottostringa VB6 (a, b, c) in silenzio esegue il rendering come a.SubString (b, c) e esplode in faccia perché lo era 1-based in VB6 e 0-based in .Net.
  3. Tutti questi impliciti facili da codice le conversioni usciranno dal lavorazione del legno, di solito sul primo PC che non ha "," come la lista delimitatore e / o "." come il decimale separatore.
  4. Le tue classi convertite non avranno i dati desiderabili - nascondendo che a la riprogettazione dovrebbe portare.

HTH

    
risposta data 24.01.2011 - 17:12
fonte
1

Dovrebbe funzionare bene per te, non c'è nulla in particolare nel passaggio da utente veloce a più sessioni che dovrebbero causare problemi.

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

    
risposta data 24.01.2011 - 14:29
fonte

Leggi altre domande sui tag