.NET 2.0: Migreren naar ASP.NET 2.0
Door Michiel van Otegem
25 juli 2008
ASP.NET 2.0 biedt veel mogelijkheden waardoor het interessant kan zijn om bestaande applicaties te migreren. Dat
geldt niet alleen voor eerdere versies van ASP.NET, maar ook voor vergelijkbare technologieën zoals ASP, JSP en PHP.
De vraag is alleen hoe je zo’n migratie aanpakt.
Voordat je überhaupt gaat denken aan hoe je gaat migreren, moet je je eerst afvragen waarom je het wilt doen. Ervaring
leert dat in de meeste gevallen de beslissing tot migratie niet gemaakt wordt door technische afdelingen, en daar
zelfs niet door geïnitieerd worden. De beslissing wordt gemaakt op hoger niveau en vaak niet om technische redenen.
Politiek en beeldvorming spelen een zeer grote rol. De beeldvorming bijvoorbeeld dat Microsoft-technologie per
definitie instabiel en onveilig is. ASP.NET 1.x heeft in de afgelopen jaren bewezen dat die beeldvorming lang niet
altijd terecht is door een stabiel, snel en veilig platform te bieden voor web applicaties. Op elk van die vlakken is
het momenteel gelijkwaardig of beter dan de concurrenten. Verschillende onderzoeken laten bijvoorbeeld zien dat een
ASP.NET 1.x applicatie minimaal even snel is als een gelijkwaardige JSP applicatie op de snelste JSP applicatie server.
De betreffende JSP server is inclusief de software echter vele malen duurder in aanschaf.
Secunia, dat het aantal veiligheidslekken van bijna alle
software bijhoudt, laat verder zien dat in ASP.NET sinds de introductie ruim 3 jaar geleden slechts vier lekken
gevonden zijn. Op zichzelf zijn dit natuurlijk geen redenen om een applicatie te migreren, maar met de komst van
ASP.NET 2.0 is dit veel aantrekkelijker geworden. ASP.NET 2.0 biedt een hoop standaardfunctionaliteit die in andere
technologieën niet aanwezig zijn. Dit scheelt niet alleen in werk, tijd en de hoeveelheid code, maar doordat de
oplossing onderdeel uitmaakt van het platform ook beter overdraagbare code, met een oplossing die waarschijnlijk
structureler is dan zelf ontwikkelde oplossingen. Dit betekent wel dat als je een migratie gaat doen om deze redenen,
je ook optimaal van de mogelijkheden gebruik moet maken. Het heeft weinig zin om er alleen voor te zorgen dat je de
bestaande applicatie werkend krijgt op ASP.NET 2.0. Dan kun je net zo goed migreren naar ASP.NET 1.x, want de
toegevoegde waarde van ASP.NET 2.0 is dan nihil. In zo’n geval zorg je er alleen voor dat de bestaande code geschikt
wordt voor ASP.NET, hetgeen betekent dat je het qua syntax en applicatiemodel aanpast. Beide zijn van ASP.NET 1.x
naar 2.0 niet gigantisch veranderd (wel uitgebreid). Wil je volledig gebruik maken van de mogelijkheden die ASP.NET 2.0
biedt, dan is het in veel gevallen verstandiger om de bestaande applicatie als een functionele specificatie te zien
van wat je wilt maken. Dat klinkt als een nogal rigoureuze stap, maar door alle standaardfunctionaliteit van ASP.NET 2.0
is de tijd die gemoeid is met een dergelijke operatie beperkt. Dat levert bovendien een applicatie op die structureel
gezien beter past op ASP.NET 2.0 en dat biedt naar de toekomst toe een beter onderhoudbare applicatie en een applicatie
die beter uit te breiden is. Als je toch besluit om de applicatie niet geheel opnieuw van de grond af op te bouwen
en echt het migratiepas te volgen, dan maakt het nogal uit wat het startpunt is. Er is een wereld van verschil tussen
migreren vanuit ASP.NET 1.x en het migreren vanuit andere technologieën, zoals PHP en JSP. Een applicatie die gemaakt
is met ASP en Visual Basic 6 hangt daar een beetje tussenin.
Migratie vanuit ASP.NET 1.x
Toen Microsoft werkte aan de eerste versie van het .NET Framework is er al heel goed nagedacht over wat er zou moeten
gebeuren als er nieuwe versies zouden komen. Want dat die er zouden komen was zeker. Microsoft is zich als geen ander
bewust van de noodzaak tot compatibiliteit met eerdere versies, maar weet ook dat dit soms gewoonweg niet mogelijk is.
Sterker nog, het .NET Framework is een stap in een hele nieuwe richting en daarmee niet compatibel met voorgaande
ontwikkelplatformen van Microsoft. De strategie wat betreft het .NET Framework is simpel: als het even kan moet een
applicatie die ontwikkeld is met een oudere versie, zonder dat deze opnieuw gecompileerd moet worden, werken op een
nieuwere versie. Dat is echter niet altijd haalbaar. Er zijn zelfs tussen versie 1.0 en 1.1 minieme verschillen die
in uitzonderlijke gevallen ervoor zorgen dat een applicatie die gemaakt is met versie 1.0 niet (goed) werkt als deze
uitgevoerd wordt op versie 1.1. Ook bij versie 2.0 zullen dergelijke verschillen onvermijdelijk zijn. Er is daarom een
backup strategie: verschillende versies van het .NET Framework moeten op dezelfde machine kunnen werken. Applicaties
kunnen aangeven met welke versies de applicatie wel of niet werkt. Met ASP.NET ligt dit iets anders, maar het
achterliggende principe is hetzelfde. Daar geef je binnen Internet Information Server welke geïnstalleerde versie van
het framework gebruikt wordt om de applicatie uit te voeren, zoals te zien in Afbeelding 1. Concreet betekent dit dat
je een aantal mogelijkheden hebt als je ASP.NET 2.0 gaat gebruiken. Je kunt hopen dat een applicatie gemaakt met
versie 1.x goed werkt, je kunt de applicatie waar nodig aanpassen en opnieuw compileren met versie 2.0 (ervan
uitgaande dat je de broncode hebt), of je kunt de oude applicatie onder een oudere versie van het framework uitvoeren.
De keuze hangt af van de situatie. Je applicatie uitvoeren op een nieuwe versie is alleen te overwegen als de oude
versie niet beschikbaar is. Opnieuw compileren doe je alleen als je de broncode tot je beschikking hebt, maar is
eigenlijk ook alleen interessant als je van plan bent een applicatie verder door te ontwikkelen onder ASP.NET 2.0.
Zou je in dat geval het "oude" gedeelte op een oudere versie van het framework uitvoeren, dan geeft dit allerlei
problemen omdat de twee delen dan in principe twee losse applicaties zijn en daardoor moeilijk als één geheel te
benaderen zijn. De andere kant om loont het alleen de moeite om op een oude versie van het framework te blijven werken
als de applicatie niet meer verder ontwikkeld wordt. Uiteindelijk is de conclusie echter simpel… migreren van
ASP.NET 1.x naar ASP.NET 2.0 is nauwelijks migreren te noemen omdat de verschillen zo klein zijn. Je moet hele
specifieke dingen doen om tegen de verschillen aan te lopen. Het is echter wel zo dat het ontwikkelmodel van ASP.NET
her en der gewijzigd is, en daar zou je eventueel je voordeel mee kunnen doen. Uiteraard is het wel zo dat je niet
direct gebruik maakt van de nieuwe mogelijkheden van ASP.NET 2.0, maar dat kan in stappen gerealiseerd worden zonder
dat daarvoor de hele applicatie weer overhoop moet.
Afbeelding 1, ASP.NET versie instellen in IIS
Migreren vanuit ASP
Een voor de hand liggend migratie pad is van ASP naar ASP.NET, omdat ASP.NET de opvolger is van ASP. ASP is van voor
het .NET tijdperk en ASP.NET (zowel versie 1.x als 2.0) is niet compatibel met ASP. Je zult aan bestaande ASP
applicaties dus wel moeten sleutelen. Gelukkig is er wel rekening gehouden met dit scenario en kun je ASP pagina’s
met kleine wijzigingen aan de praat krijgen binnen ASP.NET. Je zou er overigens ook voor kunnen kiezen ASP en ASP.NET
pagina’s in dezelfde applicatie (website) te hebben, maar dat zijn dan in feite twee afzonderlijke applicaties. De
belangrijkste consequentie daarvan is dat je geen sessie informatie kunt delen tussen ASP pagina's en ASP.NET pagina's.
Daar is op verschillende manieren omheen te komen maar ideaal zijn die niet. Het heeft dus de voorkeur om de ASP
pagina’s binnen het ASP.NET model te brengen. Hiervoor moet je voor elke pagina enkele stappen doorlopen. Om te
beginnen moet je de pagina's een andere extensie geven. Om ASP en ASP.NET uit elkaar te houden maakt ASP.NET gebruik
van de extensie .aspx. Je kunt vervolgens proberen de pagina uit te voeren, maar de kans is heel groot dat er dan een
fout optreedt. De volgende stap is dus te zorgen dat de pagina uitgevoerd wordt zonder dat er een fout optreedt.
Hiervoor zijn een aantal syntax wijzigingen nodig. Als je die allemaal hebt afgehandeld, wordt de pagina weliswaar
correct uitgevoerd, maar is de kans aanwezig dat het resultaat niet klopt. Dit geldt vooral wanneer je gebruik maakt
van COM objecten zoals bijvoorbeeld ADO voor het benaderen van een database. De gegevens die weergeven worden uit een
database zijn naar alle waarschijnlijkheid foutief, omdat ASP programmeurs over het algemeen werken met een soort
afkortingen om snel code te schrijven. De waarde van een veld opvragen wordt meestal gedaan met recordset("veldnaam"),
hetgeen een afkorting is voor recordset.Fields("veldnaam").Value. In ASP.NET levert het eerste niet de waarde op maar
een referentie naar het Field object. Om de waarde te krijgen moet je daarom de tweede manier gebruiken en dat vergt
dus enig omschrijf werk. Nu zou de pagina in principe moeten werken, maar dan wel verre van optimaal, onder andere
doordat er sprake is van late-binding (het opzoeken van het data type van variabelen tijdens het uitvoeren van de code)
in plaats van early-binding (het opzoeken van het data type van variabelen tijdens het compileren).
Als je het bovenstaande allemaal met de hand zou moeten doen, ben je wel even zoet. Gelukkig is er de "ASP to
ASP.NET Migration Assistant". Die doet het grootste gedeelte van het werk voor je. Verder geeft het waarschuwingen
over zaken die mogelijkerwijs niet werken, maar die het zelf niet kan oplossen. Dit wordt allemaal getoond in een
conversierapport zoals in Afbeelding 2. Je kunt de Migration Assistant downloaden van
http://msdn.microsoft.com/asp.net/migration/aspmig/aspmigasst/default.aspx.
Heb je de applicatie eenmaal werkend, dan begint de volgende uitdaging: de applicatie optimaliseren en zoveel
mogelijk gebruik te laten maken van wat ASP.NET te bieden heeft.
Afbeelding 2, Conversierapport van de Migration Assistant
ASP applicaties worden vaak gemaakt in combinatie met Visual Basic 6. Met Visual Basic worden dan COM componenten
gemaakt die gebruikt worden vanuit de ASP pagina’s. Je kunt die componenten zoals gezegd gewoon gebruiken, maar wel
tegen een prijs. Voor de snelheid, schaalbaarheid en veiligheid is het beter om deze componenten ook te migreren
naar (ASP).NET. Je zult dit apart moeten doen van de ASP pagina’s, en je kunt dus geen gebruik maken van de Migration
Assistant. In Visual Basic 2005 zit echter standaard de Visual Basic 2005 Upgrade Wizard, en daarmee bereik je
hetzelfde. Net als met de Migration Assistant geldt dat er geen 100% garantie is dat alles meteen werkt. Om de kans
te vergroten dat de migratie wel in één keer succesvol verloopt, kun je eerst in Visual Basic 6 de Visual Basic 6.0
Code Advisor uitvoeren die je kunt downloaden van http://msdn.microsoft.com/vbasic/downloads/codeadvisor.
De Code Advisor geeft tips over hoe je bestaande Visual Basic 6 code kunt aanpassen zodat deze makkelijker te
migreren is, overigens zonder dat de voorgestelde wijzigingen van invloed zijn op de correcte werking binnen Visual
Basic 6. Je zult zien dat kleine wijzigingen grote gevolgen kunnen hebben voor het migratieproces.
Migreren vanuit PHP
ASP.NET ligt in het verlengde van ASP en Visual Basic 6, vooral omdat er weinig verschillen zijn als het gaat om de
programmeertaal. Het ligt dus voor de hand dat migratie redelijk goed kan. Je zou denken dat dit met PHP anders ligt,
maar dat blijkt niet zo te zijn. Dit komt vooral omdat ASP en PHP veel gemeen hebben als het gaat om het
programmeermodel: een mix van script en HTML in een pagina. Het vertalen van één programmeertaal naar een andere is
niet zo heel erg ingewikkeld, helemaal als die talen redelijk dicht bij elkaar liggen qua syntax. PHP ligt wat dat
betreft het dichtste bij C#.
De moelijkheid zit ‘m in hoe bepaalde functionaliteit, bijvoorbeeld communicatie met een database, geregeld is. ASP
doet dit soort zaken via COM objecten die altijd op dezelfde manier werken, en ook aan te roepen zijn vanuit ASP.NET.
Bij PHP wordt extra functionaliteit geleverd via extensiemodules en die zijn redelijk uniek, zodat het niet altijd
mogelijk is om de functionaliteit daarvan eenvoudig te migreren. Bovendien zijn die modules niet bruikbaar in ASP.NET,
dus kun je niet gebruik blijven maken van die modules. Het migratieproces is daardoor minder makkelijk te
automatiseren, maar desondanks is er een migratiehulp beschikbaar, de PHP to ASP.NET Migration Assistant. Die is
vrijwel identiek aan die van ASP, maar heeft om de genoemde redenen een lager succespercentage. Het neemt echter veel
werk uit handen en is daardoor toch uiterst handig.
Migreren vanuit JSP
JSP hebben een redelijke gelijkenis met ASP.NET, hoewel het ontwikkelmodel van ASP.NET behoorlijk wat geavanceerder is.
Beide hebben hun fundering echter in een platform, JSP in het Java platform en ASP.NET in het .NET Framework, en die
platformen lijken meer op elkaar dan veel mensen willen toegeven. Dit wordt verder ondersteund door de gelijkenis
tussen de Java taal en C#, of zelfs J# dat de Java syntax biedt. Als het gaat om de Java code in een JSP applicatie
is het aanpassen van de taal "slechts" het aanpakken van de subtiele verschillen. Het grote werk zit in het porteren
van de aanroepen naar het platform. Hoewel dat echt regel voor regel moet gebeuren is het in zeker 50% van de gevallen
zo dat het een kwestie van naamgeving betreft, omdat beide platformen veel standaardfuncties, zoals bijvoorbeeld
string operaties, op dezelfde manier oplossen. Visual Studio bevat de Java Language Conversion Assistant (JCLA) die
een helpende hand biedt zoals de Migration Assistants voor ASP en PHP. De JCLA werkt voor zowel libraries als JSP
pagina’s, dus in theorie zou je een heel project kunnen migreren, maar de praktijk is uiteraard dat een project met
enige complexiteit niet automatisch gemigreerd kan worden. Dat is helemaal zo als een applicatie specifieke
functionaliteit van de JSP server gebruikt, wat zeker niet ongewoon is. De JCLA converteert overigens niet naar J#
zoals je zou verwachten, maar naar C#. Het kan dit op basis van een Visual J++ 6.0 (Microsoft’s oude Java omgeving)
project of de broncode van een Java of JSP project. Je krijgt dan een rapport dat op de Migration Assistants lijkt,
en code wordt voorzien van allerhande commentaar, met name Upgrade Notes (opmerkingen), Upgrade Issues (waarschuwingen),
en Upgrade Todo (nog werk aan te verrichten), zoals te zien in Afbeelding 3. Meer informatie over migratie vanuit JSP
kun je vinden op http://msdn.microsoft.com/asp.net/migration/jspmig/.
Afbeelding 3, Fragment van geconverteerde Java code met commentaar
Tot slot
Het is Microsoft eraan gelegen om migratie naar ASP.NET zo makkelijk mogelijk te maken, zodat de keuze voor migratie
makkelijker te maken is wanneer men eenmaal kiest voor ASP.NET. De documentatie is daarom goed en de diversie migratie
assistenten geven goede eerste hulp bij migratie. Het blijft natuurlijk uiteindelijk de kunde van de ontwikkelaars om
een echt goede applicatie neer te zetten op het nieuwe platform. De evolutie van de applicatie kan na de migratie
echter snel gedaan worden door alle mogelijkheden die ASP.NET 2.0 standaard heeft.
Dit artikel is eerder verschenen in NetOpus, mei 2005.
|
