Jak działają hybrydowe aplikacje VB6 / .Net w świecie rzeczywistym?

Utrzymuję aplikację VB6 i uczymy się, jak przeprowadzić migrację do .Net. Rozważamy to stopniowo, wdrażając nowe funkcje w widocznych klasach COM .NET i powoli migrując istniejącą funkcjonalność. Znalazłem kilka pouczających przykładów „Hello World” na temat tego, jak to zrobić i działa dobrze z naszą aplikacją. Ale jak wygląda rzeczywiste zachowanie tych aplikacji hybrydowych? Czy są stabilne, łatwe w utrzymaniu? W szczególności nasz program polega na tym, że więcej użytkowników na tym samym komputerze będzie z niego korzystać, zmieniając konta użytkowników.

EDYCJA: Aplikacja VB6 odczytuje dane z połączenia USB i zapisuje je w bazie danych Access. Użytkownik może wywoływać różne widoki danych. Dane są buforowane w urządzeniu sprzętowym, więc przerwy w ich czytaniu nie są śmiertelne.

EDYCJA 4 października 2015: Czas na kontynuację: Nadal jesteśmy w trakcie wymiany istniejącego kodu VB6 krok po kroku na .Net. Najpierw przyjęliśmy procedury dostępu do danych, następnie logikę biznesową, a obecnie jedną formę po drugiej konwertowano na WPF. Rzeczywiście skończyliśmy przepisywać każdy kawałek kodu, który przekonwertowaliśmy (w VB.Net), ale mogliśmy to zrobić powoli i jednocześnie poprawić funkcjonalność. Aplikacja hybrydowa przetrwała przejście na Windows 8, 8.1 i 10.

EDYCJA 9 marca 2018 r .: W przyszłym miesiącu wydamy w pełni przekonwertowany kod. Aplikacja hybrydowa będzie obsługiwana przez co najmniej rok dłużej. Pokazuje głównie problemy na ekranach o wysokiej rozdzielczości, ale w przeciwnym razie działa dobrze. Szczerze mówiąc, mamy więcej problemów z obsługą ze względu na uszkodzone instalacje .Net Framework i uszkodzone instalacje zależności (wśród nich SQL Server LocalDb) niż problemy z kompatybilnością z bazą kodu VB6 ...

Odniosłem niesamowity sukces, wystawiając .NET na VB6 poprzez interfejsy COM. W ten sposób mogliśmy wstępnie refaktoryzować ogromną ilość kodu VB6 i skonfigurować ścieżkę aktualizacji do .NET. Pamiętaj tylko, że idiomatic VB6 nie przekłada się dobrze na C #, a nawet VB.NET, więc będziesz chciał ostrożnie postępować.

Jedynym problemem, który mieliśmy dość denerwujący, była nadmierna liczba przebudów, które musieliśmy wykonać z powodu zmian w publicznym interfejsie COM. Zostało to złagodzone przez Visual Make .

FWIW, z mojego doświadczenia wynika, że ​​konieczność uaktualnienia aplikacji VB6 do .Net stanowi idealną wymówkę do ponownego napisania. O ile oryginalne kodery nie były genialnymi wizjonerami, techniki rozpowszechnione w VB6 rzadko przenoszą się czysto do .Net.

Niektóre rozkosze, które napotkasz:

1. Otrzymasz odniesienia do Microsoft.VisualBasic, których tak naprawdę nie chcesz.
2. Będą trudnymi do znalezienia błędami, na przykład, gdy podciąg VB6 (a, b, c) cicho renderuje się jako a.SubString (b, c) i wysadza się w twarz, ponieważ był oparty na 1 w VB6 i 0 w oparciu o .Net.
3. Wszystkie te łatwe do zakodowania niejawne konwersje wyjdą z stolarki, zwykle na pierwszym komputerze, który nie ma „,” jako ogranicznika listy i / lub „.” jako separator dziesiętny.
4. Twoje skonwertowane klasy nie będą miały pożądanego ukrywania danych, które powinno przynieść przeprojektowanie.

HTH

Powinno to działać dobrze, nie ma nic szczególnego w szybkim przełączaniu użytkowników / wielu sesjach, które powinny powodować problemy.

Jeśli chodzi o łatwość konserwacji, pamiętaj, że hybrydowy VB6 / VB.NET powinien być jedynie rozwiązaniem tymczasowym: Twoim planem powinna być pełna migracja do VB.NET w miarę upływu czasu.