Najlepsza strategia przenoszenia z VB6 do .NET

Question

Moja firma ma mnóstwo aplikacji starszych, które są napisane w VB6.

Jesteśmy w przejściach z przenoszenia aplikacji VB6 do .NET (w szczególności 3,5).

Jaka byłaby najlepsza strategia przenoszenia formularza VB6 do .NET?

UWAGA Poniżej aktualizacja powinna iść do „Project Management” i nie ma nic wspólnego z głównym pytaniem.

[UPDATE]: Dziękujemy za przesłaną ocenę dotychczas
Teraz są więcej wątpliwości, że pop-up są

1. jak można przypisać programistów do opracowania nowych aplikacji?
2. Czy powinien istnieć specjalny jednorazowy dział aktualizacji, który zamieni stare aplikacje na nowe? Czy też każdy deweloper powinien uczestniczyć w procesie konwersji ?
3. Czy tylko programiści powinni uczestniczyć w konwersji? Czy deweloperzy Junior ? lub mieszane?

Wydaje się, że im więcej myślę o tym tym problemie, więcej pytań po prostu pokazuje w górę.

Answer 1

Oczywiście jest to duże przedsięwzięcie, które wymaga dużej ilości pracy.
Moją radą byłoby potraktować to jak bardzo długoterminowy projekt.

Mieć jasny cel, który dotyczy najważniejszych problemów, takich jak bezpieczeństwo, odporność, łatwość konserwacji i przyszłość aplikacji.

Po uzgodnieniu tego przez zainteresowane strony, opracuj prototypowy system, aby przetestować swoje założenia, gdzie możesz wypróbować C# vrs VB.net lub MVC vrs Webforms. Przydzielę do tego twoich najlepszych programistów.

Następnie zacznij od jednego ze swoich małych starszych systemów i zbuduj podstawowe komponenty, których będziesz używał ponownie w innych obszarach.
Na tym etapie zacznij od starszych programistów, ale każdy musi się zaangażować i zapoznać się z nowym środowiskiem.
Zapewni to, że wszyscy zostaną przeszkoleni w tym samym czasie i nikt nie zostanie pozostawiony.
W zależności od tego, ile masz aplikacji, chciałbym obrócić programistów, aby wszystkie systemy mogły z tego korzystać.

Również wszystkie nowe prace należy wykonywać w języku .net, nie w VB6.

Stopniowo konwertuj każdą ze starszych aplikacji. (Przekształcałbym je tylko wtedy, gdy ulegają zmianie lub są wyraźne korzyści z ich aktualizowania.)

Powinno to zapewnić solidne ramy do wykorzystania w przyszłości, zapewniając jednocześnie, że funkcjonalność użytkownika nie jest utrudniona przez migracja.

Na przykład:
Pracowałem w firmie, która miała około 40 aplikacji VB.
Z czasem przenieśliśmy te wszystkie do C#, a teraz (5 lat później) mamy około 150 aplikacji C# (wszystkie w .net 2.).

Wszystkie mają wspólną strukturę, dzięki czemu są łatwe w utrzymaniu i rozszerzane w razie potrzeby.

Answer 2

chciałbym zacząć z narzędziami Microsoftu:

http://msdn.microsoft.com/en-us/library/aa480541.aspx

Answer 3

Zobacz to:
https://stackoverflow.com/questions/507291/should-we-select-vb-net-or-c-when-upgrading-our-legacy-apps

Oczywiście, C# vs VB.Net to tylko jedna część.

Na przykład inną rzeczą do rozważenia jest, jeśli chcesz skorzystać z tej okazji, aby przenieść te aplikacje do intranetu, jeśli jeszcze tego nie zrobiłeś. Lub jak głęboko chcesz zagłębić się w stos Microsoftu. Czy WinForm jest wystarczający, czy na przykład chcesz użyć WPF?

Answer 4

Może się okazać przydatny następujący artykuł: http://www.vsj.co.uk/articles/display.asp?id=756

Answer 5

spróbować wymienić podstawowe funkcje z bibliotek .NET COM włączoną. "Hollow" swoje istniejące aplikacje VB6, przenosząc funkcjonalność do .NET bit po bicie.

Uwaga na pełne napisy. Choć kuszą "ponieważ to czysty krój" - zwykle szaleństwo przedkłada! Przeczytaj "Skuteczne działanie ze starszym kodem" Michaela Feathersa jako przygotowanie. Mimo że książka nie mówi konkretnie o "przechodzeniu z jednego języka na drugi", pokazuje wiele pułapek, z którymi się spotkasz.

Sądzę, że wszyscy deweloperzy powinni mieć zdefiniowane przedziały czasowe, w których wykonują migrację starszych aplikacji, które wcześniej opracowali. Ponieważ mają już wiedzę na temat domeny i znają problematykę, powinny być najbardziej produktywne.

Answer 6

Oto adaptacja mojego answer na podobne pytanie.

Konwersja dużych programów automatycznie jest lepszym wyborem niż przepisywanie. Powszechną pułapką jest rozpoczęcie optymistycznego przepisywania dużego oprogramowania, wczesny postęp w naprawie niektórych znanych błędów w starej architekturze, a następnie ugrzęźnięcie w funkcjonalności, którą właśnie przyjmujesz za pewnik. lat. W tym momencie twoje zarządzanie zaczyna się denerwować i wszystko może stać się bardzo niewygodne.

... i oto blogu przez Microsofty że agrees with me:

Wiele firm, z którymi pracowałem w pierwszych dniach .NET spojrzał najpierw na przepisanie napędzany częściowo przez silne pragnienie, aby poprawić podstawową architekturę i struktury kodu w tym samym czasie, w którym przeszły do ​​.NET. Niestety wiele z tych projektów napotkało na trudności, a kilka z nich nigdy nie zostało ukończonych.Problem starali się rozwiązać był zbyt duży

To doskonała Microsoft page zaleca dwa narzędzia migracji osobę trzecią lepszy niż underpowered wbudowanym VB.NET uaktualnić Wizard - Artinsoft i CodeArchitects VBMigration. Artinsoft napisał wbudowany kreator aktualizacji VB.NET, to jest ich ulepszona wersja. A CodeArchitects został założony przez Francesco Balena, który napisał niektóre z classic books na VB6 i VB.NET.

tej samej stronie Microsoft mówi:

Wykonywanie kompletny tekst poprawiony do .NET jest znacznie bardziej kosztowne i trudne do dobrze [niż konwersja] ... nie polecamy tej metody tylko dla niewielkiej liczby sytuacji.

---

EDIT: Sung mówi w komentarzach: „Nie jestem wielkim fanem generacji auto kodu, ponieważ jest to trudniejsze do debugowania początkowo i może trwać tylko tak długo, jak będzie trzeba przerobić całość” . Muszę się zdecydowanie nie zgodzić. Generalnie również nie jestem fanem generowania kodu, ale w tym przypadku wynikowy kod będzie wyglądał identycznie jak w oryginalnym VB6 i powinien być prawie całkowicie funkcjonalny. Nie próbowałem jeszcze samodzielnie tych narzędzi, ale z ich obietnicy jest spełniona ta customertestimonials.

I powtórzyć porady Microsoft tuż powyżej, w oparciu o ich doświadczenia pomagając wielu migracje - „kompletnym przepisanie jest znacznie bardziej kosztowne i trudne niż konwersja [podkreślenie moje]” - płaski sprzeczność z przypuszczeniem, że to może potrwać w tym samym czasie. Jeśli chcesz poprawić strukturę VB6, migracja, to stopniowe refaktoryzowanie może być znacznie bardziej opłacalne niż przepisywanie.