|
Tijdens het bouwen van een webapplicatie is het voor de ontwikkelaar erg eenvoudig dat hij/zij fouten kan opsporen in de code door middel van debugging. Dit wil zeggen dat een ontwikkelaar tijdens het uitvoeren van een test op de software mee kan kijken met de code om zo precies te zien wat er gebeurd en waarom eventuele fouten optreden.
Wat veel (nieuwe) gebruikers van .NET echter niet weten is dat tijdens het bouwen van een website op de ontwikkelmachine, deze in een speciale ‘debugging’ mode draait. Dit heeft tot gevolg dat wanneer een build-actie wordt gestart op de applicatie er niet alleen een DLL-wordt gebouwd met machinetaal (of in het geval van .NET de zogenaamde .NET Intermediate Language), maar tevens een bibliotheek met daarin alle code van het project. Deze bestanden met debug symbols zijn in de bin-directory te herkennen aan de zogenaamde PDB extensie.
Deze bestanden bieden de ontwikkelaar dus veel voordeel op de ontwikkellocatie. Het wordt echter iets anders wanneer deze files op een productieserver terecht komen. Het probleem is dat je hier echter niet direct iets van zult merken omdat het niet meteen zal leiden tot fouten in de applicatie. Er zal echter vooral op het gebied van performance een nadelig effect op gaan treden. Wanneer de webapplicatie detecteert dat deze bestanden aanwezig zijn zal de applicatie automatisch enkele optimalisaties niet doorvoeren en derhalve blijven draaien in de eerder genoemde debugging mode.
Een simpele oplossing
Voordat een webapplicatie kan worden geupload naar de productieomgeving zal de ontwikkelaar de applicatie eerst moeten voorbereiden. Hiervoor zijn een aantal simpele stappen te doorlopen.
1. Project in ‘release’ mode compileren.
Het instellen van ‘release’ mode in een project is zo eenvoudig als het openen van een dropdown in Visual Studio en het selecteren van Release. De betreffende dropdown is standaard aanwezig in de Visual Studio IDE (zie afbeelding).
Wanneer nu vervolgens het project wordt gebuild, zullen er geen Debug Symbols (PDB) files worden gegenereerd. Dit betekent niet alleen dat de website een betere performance zal hebben, maar ook dat de code van je site (iets) veiliger is omdat één en ander niet zo gemakkelijk te decompileren is naar je originele code (een veiligere manier hiervoor is code obfuscation, hierover een andere keer meer).
2. Aanpassen website configuratie
Een tweede stap voor het releasen van een website en hiermee tevens verbeteren van de performance is een juiste setup van de web.config file in de root van je applicatie.
Hiervoor hoef je ook slechts één enkele wijziging door te voeren. Het betreft hier de tag compilation. Hierin staat de waarde ‘debug’ standaard op ‘true’. Dit heeft niet direct invloed op het compileren wanneer je in Visual Studio je solution build, maar heeft wel betrekking op een website in productie.
In ASP.NET bestaat iedere pagina binnen een webapplicatie uit twee delen; de HTML en de codebehind. Wanneer je in Visual Studio een solution build worden alle codebehind pagina’s uit het project bij elkaar geschraapt en gecompileerd tot één enkele DLL. Met de HTML wordt op dat moment niks gedaan. Echter, wanneer je binnen een website een pagina opvraagt, zal op dat moment de HTML pagina alsnog worden gecompileerd omdat hier, net als in codebehind, via server-side scripting .NET code geplaatst kan worden. Wanneer in de web.config de waarde debug=”true” aangegeven staat zal het compileren van deze scripts dus niet optimaal gebeuren.
Om dit te voorkomen zet je de waarde van debug op false:
3. Kopiëren van de websitebestanden
Een fout die regelmatig wordt gemaakt bij het uploaden van een .NET webapplicatie naar een productieserver is het feit dat men de lokale ontwikkelfolder 1-op-1 naar de server upload. Er worden dan echter te veel bestanden geupload, wat niet alleen de performance nadeling beïnvloed, maar ook nog eens tot gevolg heeft dat bepaalde gebruikers van de server je code direct kunnen lezen omdat de .VB of .CS immers gewoon op de server staan.
Om dit te voorkomen biedt Visual Studio je de mogelijkheid om een kopie te maken van een webapplicatie waarbij alleen de direct benodigde bestanden worden gekopieerd.
Om dit te doen ga je in Visual Studio naar Project / Copy Project.
LET OP: voordat je aan deze stap begint moet je eerst de vorige twee stappen hebben uitgevoerd en je applicatie builden.
Hierna wordt je gevraagd om een aantal velden in te vullen. Het is sterk aan te bevelen om hierbij een aparte map te maken onder de webroot waar je al deze ‘productiekopieën’ in kunt plaatsen zodat ze altijd op één plek te vinden zijn (in de afbeelding hieronder is gekozen voor de map staging).
Let er op dat je in de meeste gevallen moet kiezen voor de File Share methode omdat de FrontPage methode simpelweg niet werkt. Het pad wat je vervolgens invult onder Path moet verwijzen naar project folder zoals je hem in het bovenste tekstvak hebt opgegeven.
Zoals je kunt zien staan bij de onderste opties alle verschillende mogelijkheden voor het kopiëren van de bestanden, hierbij kies je voor de eerste optie om alleen de benodigde bestanden te kopiëren.
Na het kopiëren van de bestanden heb je op je pc een map die je bijna direct kunt uploaden naar de server. Het woord bijna in de vorige zin slaat op het feit dat je er wel voor moet zorgen dat je bij het uploaden geen configuratiebestanden overschrijft die reeds op de server aanwezig zijn en specifieke instellingen voor de server bevatten welke verschillen van je lokale ontwikkelomgeving.
Wanneer je wilt voorkomen dat er bepaalde bestanden mee worden gekopieerd bij het releasen van een website kun je deze bestanden bij de eigenschappen in Visual Studio de property Build Action op ‘none’ zetten:
Wanneer je bovenstaande stappen hebt doorlopen zal het .NET worker process op de server er voor zorgen dat je webapplicatie efficiënter zal draaien, wat de performance duidelijk ten goede zal komen.
|