Är du drabbad av Visual Basic?

Bakgrund

Under sin storhetstid på 1990-talet var Visual Basic ett populärt programmerings-språk och dess raison d’être var att göra grafiska windowsapplikationer och rapid prototyping. Eftersom språket hade nybörjare och amatörer som målgrupp så kunde erfarna utvecklare snabbt nå imponerande resultat.

Mellan 1991 och 1998 kom Visual Basic med tillhörande utvecklingsmiljöer,
komponentbibliotek och runtimes ut i flera versioner, där version 6.0 var den sista. Visual Basic 6.0 ersattes 2002 av Visual Basic .NET, även kallat VB 7.0, som är att betrakta som ett helt nytt programmeringsspråk som har mer gemensamt med C# än med tidigare versioner. Visual Basic .NET vidareutvecklades sedan till Visual Basic 2015, som är ett i allra högsta grad levande och modernt programmeringsspråk.

Problemet är inte nya Visual Basic .NET, utan de gamla versionerna av Visual Basic till och med version 6.0. Dessa versioner benämns hädanefter klassisk Visual Basic.

Microsoft slutade supporta alla versioner av klassisk Visual Basic år 2008, även om man fortfarande garanterar att
VB runtime, som behövs för att köra Visual Basic-applikationer, kommer fortsätta fungera under Windows 7, 8 och 10.

Så vad är problemet? VB runtime fortsätter fungera och det är väl ingen som använder ett nästan 20 år gammalt språk, eller?

Nuläge

Det kanske kommer som en fullständig överraskning, men faktum är att det fortfarande finns mängder av affärskritiska applikationer skrivna i Visual Basic 6.0. Det är också ett av huvudskälen till varför många företag har svårt att överge det snart 15 år gamla operativsystemet Windows XP, då detta operativsystem är det sista med fullt stöd för klassisk Visual Basic.

Jag har också stött på utveckling av nya applikationer i klassisk Visual Basic 6.0 så sent som 2010 och gör man en sökning efter jobbannonser så ser man att expertis inom klassisk Visual Basic fortfarande efterfrågas.

Bara under senaste året har minst två kunder kontaktat Addiva angående affärskritiska applikationer gjorda i klassisk Visual Basic. Följaktligen är klassisk Visual Basic långt ifrån dött.

Kompatibilitetsproblem med Windows 7 och senare

Åter till grundproblemet. Även om Visual Basic-applikationer, som använder basfunktionalitet, fortfarande går att köra på Windows 7, 8 och 10 så finns följande problem:

1. Majoriteten av Visual Basic-applikationer är helt beroende av ovanliga, och ofta gamla, COM-komponenter, ActiveX-komponenter eller kontrollbibliotek. Att få dessa att fungera på Windows 7 och senare är ofta en stor utmaning, speciellt då dessa operativsystem har strängare säkerhetsmodeller där User Account Control (UAC) vanligtvis förvärrar problemen. Windows i 64-bitar skapar också problem.
2. Enligt Microsoft ska utvecklingsmiljön för Visual Basic 6.0 fungera på Windows 7 och senare, men enligt praktiska erfarenheter fungerar det är långt ifrån problemfritt. Speciellt installationen är ett problem.
3. Därtill är det efter 20 år svårt att få tag i resurser som kan klassisk Visual Basic och efterfrågan är för låg för att nya personer ska utbildas.

Lösningar

Vad är lösningen? Vad ska man göra med gamla Visual Basic-applikationer?

Som vi har sett så är det en dålig lösning att lämna programmen som de är, åtminstone långsiktigt, eftersom stödet för Visual Basic vittrar bort. Redan nu kan många applikationer inte köras på Windows 7 och senare.

Det finns tre lösningar:

1. Migrera till .NET – med ett migreringsverktyg som översätter VB6-kod till motsvarande .NET-kod

2. Bygg ut med .NET – Ny funktionalitet görs i .NET och kopplas ihop med det ursprungliga VB-programmet med COM interop.

3. Skriv om för hand i .NET

Migrera till .NET

Alternativ ett, migrera till .NET, låter vid en första anblick lovande och det finns många migreringsverktyg som säger sig göra jobbet, till exempel från Microsoft. Ärligt talat, så har dessa en omöjlig uppgift. De kan hjälpa lite, men det finns många inneboende problem.

Det största problemet är inte språket, som översätts hyggligt bra i de flesta fall. Istället är det klassbibliotek, komponenter, tredjeparts COM-komponenter och ramverket runt användargränssnittet som skapar problem.

ActiveX-komponenter fungerar i viss mån i .NET, men kan ofta orsaka problem. För att göra saker ännu värre så använder avancerade Visual Basic-applikationer ofta smarta hack och API-anrop. Slutligen har COM en helt annan arkitektur i .NET. Hur ska ett migreringsverktyg kunna reda ut allt detta
med framgång?

Bygg ut med .NET

Alternativ två är inte heller speciellt attraktivt. Att bygga ut ny funktionalitet med .NET, och integrera med den existerande Visual Basic-applikationen med hjälp av interop skapar problem med dålig prestanda och svårlösta programmeringstekniska utmaningar. Annars kan det vara en väg framåt för att gradvis göra sig av med Visual Basic-applikationer.

Skriv om för hand i .NET

Alternativ tre, att skriva om hela applikationen för hand är tyvärr oftast den bästa lösningen. Jag säger ”tyvärr” eftersom det är en besvärlig väg att gå:

• Omskrivningar tar ofta längre tid, är dyrare och är mer komplexa än förväntat.Omskrivningar har ingen direkt kundnytta.

• Omskrivningar tar resurser som i normala fall hade kunnat användas för kundsupport och nyutveckling.
• Stor risk att funktionalitet går förlorad på grund av bristfällig dokumentation och dålig förståelse av mjukvaran.

Fallstudie – En kundapplikationer

För att förstå varför omskrivning är rätt väg att gå behöver vi titta på ett exempel från ett verkligt fall av en Visual Basic-applikation.

Applikationen är på många sätt representativ, med en kodbas på 180 000 rader och en mängd dialoger och det finns många anledningar till att applikationen inte kan migreras eller översättas rakt av till .NET.

För det första används obsoleta teknologier som saknas i .NET:

• Ålderdomligt och inkonsekvent användargränssnitt
• Hemmagjort flerspråksstöd i MS Access 2003
• DoEvents för att göra bakgrundsjobb istället för asynkron programmering med async och await.
• Licenskontroll med hårdvarudongel.
• Tredjepartskomponenten ActiveBar Control från 1999.
• Databasaccess med DAO mot Access 2003. Idag används tekniker byggda på ADO.NET och SQL Server.
• Många dialoger skapas dynamiskt på ett sätt som saknar motsvarighet i .NET

För det andra så lider applikationen av en mängd programmeringstekniska missgrepp då den har byggts ut av otaliga utvecklare under årens lopp:

• Felhantering saknas
• Död kod och många variabler och dialoger som inte använts
• Generös användning av globala variabler och instansvariabler.
• Variabler har intetsägande namn och saknar initialvärden
• Lösenord sparas i filer i klartext
• Inget skydd mot SQL injection

För det tredje har programmet en undermålig arkitektur utan lager och separation. Databasfrågor är hårdkodade mitt i VB-koden och ofta uppblandad med beräkningar och kod som påverkar det grafiska gränssnittet.

Att ett migreringsverktyg skulle kunna reda ut det här är orealistiskt.

Slutsats

Då stödet för klassisk Visual Basic blir allt sämre i nyare Windowsoperativsystem så är det angeläget att planera för migrering av existerande applikationer.

Som vi har sett så är det inte språket som är den stora utmaningen vid en migration. Utmaningen ligger istället i att ersätta gamla tredjepartskomponenter och obsoleta teknologier med moderna motsvarigheter. Jobbet är tidsödande och manuellt, men med noggranna val av plattform och arkitektur går det att bygga framtidssäkra affärskritiska applikationer för att möta morgondagens utmaningar.

Text:Carl-Johan Aberger
Utvecklare på Addiva Software and Embedded Services

Läs ADDERA online: https://issuu.com/addivaab/docs/addera_2016_social_media_web/1

Bild källa: http://www.brandsoftheworld.com/