|
De web.config is de standaard oplossing voor het configureren van de asp.net websites. Zowel instellingen van ASP.Net zelf als door de ontwikkelaar gekozen configuratie-instellingen kunnen daarin opgeslagen worden. |
|
<?xml version="1.0"?>
<configuration>
. . . . .
<appSettings>
<add key="sleutel" value="tekst" />
</appSettings>
</configuration>
In dit voorbeeld kun je de appSettings vast wel terugvinden maar een gemiddelde web.config zal eerder enkele honderden regels aan XML elementen bevatten en dat is een stuk minder overzichtelijk.
De oplossing is dan om de application settings sectie te verhuizen naar een apart bestand en deze te benoemen als config source in de oorspronkelijke web.config sectie:
<?xml version="1.0"?>
<configuration>
. . . . .
<appSettings configSource="config\web.appsettings.config" />
</configuration>
Hier is het aparte bestand met de veelzeggende naam ‘web.appsettings.config' in een map, genaamd ‘config', geplaatst. In dat bestand staat dan de uiteindelijke appSettings sectie, dus zonder de configuration omarming etc.
<appSettings>
<add key="sleutel" value="tekst" />
</appSettings>
Bij het starten van de website wordt de web.config samengevoegd met alle gerefereerde bestanden. Er is dus voor de rest geen verschil tussen het originele configuratiebestand en de combinatie van al die configuratiebestanden. Sterker nog, tooling zoals de Asp.NET Configuration website ( Menu | Website | ASP.NET Configuration) blijven gewoon werken met deze situatie en schrijven ook gewoon in de aparte bestanden.
Secties kunnen ook versleuteld worden zodat de inhoud niet meer te lezen is. De inhoud van een sectie wordt in de web.config gesleuteld. Kijk voor een prima uitleg op de site van 4 guys from Rolla. Dit werkt dus ook nog steeds bij een sectie in een apart bestand. Hier is een voorbeeld van de connectionstring sectie buiten de web.config:
<connectionStrings configProtectionProvider="DataProtectionConfigurationProvider">
<EncryptedData>
<CipherData>
<CipherValue>AQAAAN [knip] tVZEu</CipherValue>
</CipherData>
</EncryptedData>
</connectionStrings>
Een dergelijke versleuteling is dus perfect als in de connectionstring bv. gevoelige informatie zoals een inlognaam of wachtwoord staat. Deze informatie is dus niet meer leesbaar hoewel ontsleutelen wel mogelijk blijft, afhankelijk van de gekozen versleutelmethode. Bijkomstig voordeel is dat hier dus simpel bestanden vervangen kunnen worden, bv. bij gebruik van een machine afhankelijke versleuteling.
De tweede sectie en volgende secties moeten allen in apart bestanden ondergebracht worden. Verschillende secties kunnen niet samen ondergebracht worden in een enkel bestand. Dit kan je tot de verleiding brengen om alle mogelijke secties te verhuizen naar aparte bestanden.
Ik heb hier de complete web.config van een nieuw Asp.NET project teruggebracht tot nog maar enkele regels XML door secties te verplaatsen. De overige heb ik verwijderd en de applicatie start nog gewoon op:
<?xml version="1.0"?>
<configuration>
<system.web>
<compilation configSource="config\web.compilation.config" />
<authentication configSource="config\web.authentication.config" />
<customErrors configSource="config\web.customErrors.config" />
<pages configSource="config\web.pages.config" />
<httpHandlers configSource="config\web.httpHandlers.config" />
<httpModules configSource="config\web.httpModules.config" />
</system.web>
<system.codedom configSource="config\web.system.codedom.config" />
<appSettings configSource="config\web.appSettings.config" />
<connectionStrings configSource="config\web.connectionStrings.config" />
</configuration>
Niet iedere sectie kan zondermeer verhuisd worden maar dit ruimt wel lekker op :-)
Nu kun je dus de keuze maken om werkelijk alle secties in aparte bestanden onder te brengen zodat eventuele wijzigingen verdeeld worden over verschillende bestanden of om allen statische instellingen te verhuizen en de wijzigingen te verzamelen in de web.config. De laatste optie spreekt mij het meeste aan. Het ging er aan het begin van dit verhaal vooral om dat systeembeheer tegen zichzelf beschermd kan worden en dat de te onderhouden instellingen weer overzichtelijk worden. Laat de te onderhouden settings dus gewoon in de web.config en verhuis de rest.
Share this | 922 keer bekeken | 3 reacties
Heindirk de Laat reageert, op November 7, 2008 om 08:20 (GMT +01:00):
Mark, wat bieden Microsoft of anderen voor oplossing om tijdens de installatie configfiles aan te passen? En hoe doe je dat als je meer omgevingen hebt (ontwikkel, test, acceptatie, productie)?
Marco Pankow reageert, op December 16, 2008 om 10:31 (GMT +01:00):
Goed en duidelijk verhaal, Sander.Thanks.






Mark Lammerse reageert, op November 6, 2008 om 10:23 (GMT +01:00):
Het belangrijkste aspect aan web.config files is dat het niet het middel is om een website te configureren, maar alleen de oplossing.. dat behoeft uitleg:Dus je hebt een website met een database erachter. Daarvoor gebruik je als goede ontwikkelaar dus een laag van objecten die requests van de interface vertalen naar objecten in de database. Ongeacht het abstractieniveau zul je dus minimaal een component moeten hebben die die database moet kunnen vinden en moet aantonen dat die de db mag gebruiken en heeft dus een connectionstring nodig. En die staat meestal in de web.config. Zover niets nieuws..
Wellicht wel nieuw is dat een goede oplossing een installer heeft van dat datalaag-component en dat component zorgt zelf voor de juiste bewerkingen in de web.config.. tijdens installatie, de-installatie en wellicht zelfs configuratie.
Voor een kleine simpele website wellicht overkill, maar daar zijn web.config bestanden ook klein en simpel/overzichtelijk.
Een Sharepointsite met een aantal custom solutions en een aantal webparts; ononkoombaar, tenzij je met gigantische last wilt komen te zitten van configuratie en management.
Het is dus aan te bevelen iig te onderzoeken welke delen van de web.config wel en welke niet handmatig mogen worden bewerkt, en deze als zodanig op te delen. Maar in het algemeen is het zo dat als je een web.config handmatig moet aanpassen als je een nieuwe versie installeert van je datacomponent of ander component in je website, er eigenlijk iets mis is.