(Lezen is geheel voor eigen risico!

Het gevaar bestaat dat je .NET leuk gaat vinden....)

 Eén van de sterke punten van het .Net Framework blijft de enorme hoeveelheid functionaliteit die ontwikkelaars ter beschikking staat. Stelregel moet steeds zijn, wat ik zoek zit er ergens in,de kwestie is waar en hoe. Niet zelf schrijven dus, onderzoeken en rondvragen.

Zeer recent kwam ik een artikel van Duncan Mackenzie tegen in MSDN magazine van april 2005 over het opslaan van instellingen. Aangezien ik bezig ben met voorbeeldcode in VO.NET lijkt dit me een uitstekend voorbeeld om uit te werken in VO.net.  Iedere VO ontwikkelaar zal in z’n toolbox classes hebben om met instellingen om te gaan.

Er zijn meerdere varianten van instellingen te bedenken die door applicaties geimplementeerd moeten worden. Ten eerste applicatiespecifieke instellingen, zoals bijvoorbeeld de database connectie string of een licentiecode. En dan gebuikerspecifieke settings die dus uniek moeten zijn per gebruiker en ook door de gebruiker zelf impliciet of expliciet kunnen worden gewijzigd. De applicatieinstellingen zullen meestal tijdens de installatie of door een beheerder worden aangepast. Het is zelfs verstandig te zorgen dat gebruikers deze instellingen niet zelf kunnen aanpassen. Voorbeelden van gebruikersinstellingen die impliciet zijn zijn de laatste 5 bekeken orders of de positie van formulieren of kleuren. Ook de taalkeuze is zo’n instelling die je graag per gebruiker opslaat.

Bovenstaande klinkt waarschijnlijk bekend, en je hebt vast een eigen oplossing gebouwd op basis van .ini files, registry instellingen of in een database. Het goede nieuws is dat Windows voorzieningen voor dit soort dingen heeft, en dat het .Net Framework voorziet in een abstracte laag om hier gebruik van te maken.

AppSettings

Eerst de niet gebruiker gebonden instellingen. Deze instellingen worden door het Framework opgeslagen in een speciale configuratie file met de default naam App.config. Voeg je die met Visual Studio toe aan je project dan zorgt VS ervoor dat er een kopie terecht komt in dezelfde map als de .Exe file met als naam ExeFileNaam.Exe.Config. De instellingen zijn vervolgens te benaderen via de ConfigurationSetttings.AppSettings class.

 
Het VS verhaal gaat natuurlijk nog niet op voor VO.NET maar de .Net Classes zijn natuurlijk wel bruikbaar om deze instellingen op te vragen.

Op te vragen? Ja op te vragen, schrijven naar die Settings kan namelijk niet met de AppSettings class en dat is ‘By Design’.

Zoals eerder opgemerkt zijn de appSettings bedoeld om te beheren als beheerder (met Notepad, XMLSpy of een andere editor) en heeft een gebruiker helemaal geen rechten deze instellingen te wijzigen. Sterker, de gebruiker heeft zelfs default geen rechten om te schrijven in de Program Files tak van het systeem, en dat is precies waar de Config-file zich bevindt. Dat is goed, want anders zou een andere gebruiker op dezelfde computer met de instellingen van de vorige gebruiker geconfronteerd worden. Voor de Applicatie settings is dit dus een prima oplossing, voor de gebruiker specifieke echter niet.

De volgende VO.Net code leest de setting-file key “Database” (zie afbeeld hierboven) uit:

Eenvoudig genoeg, de AppSettings class bevat een ‘NameValueCollection’, geladen vanuit de XML-file en de NameValueCollection heeft een Get methode waarmee op basis van een sleutel (de naam) een waarde kan worden opgevraagd. De NameValueCollection Class op zich heeft ook een Set en Add method maar de ConfugurationSettings Class heeft geen ‘Save’ method. Optioneel kan ook gebruik worden gemaakt van de AppSettingsReader class.

UserSettings

Object georienteerd zoals we inmiddels allemaal zijn en denken vinden we het inmiddels normaal Classes en objecten te gebruiken om informatie in op te slaan, echter het persistent maken van die data in een bestand op schijf doen we vaak nog op traditionele manieren. In VO-32 bijvoorbeeld in de registry, of gemakkelijker in te zien en te onderhouden in een .Ini bestand. Sommige ontwikkelaars gaan zelfs al zover om dat in XML bestanden te doen, om voor de hand liggende, vaak goede redenen als uitwisselbaarheid en het kunnen valideren aan de hand van schema’s. Doen we dit via een XML-parser dan is daar vaak redelijk wat code voor nodig. Het .Net Framework neemt ons dit geheel uit handen, weer minder eigen code om te onderhouden!

XML Serialisatie

De XmlSerializer class kan op basis van de typeinformatie van een Class de juiste XML voor ons genereren en met behulp van een StreamWriter die informatie persisteren in een (xml) bestand.

Hieronder UserSettings.prg waarvan de code voor zich zal spreken

En hier, te zien in Visual Studio het resultaat:

Inlezen (DeSerializen) werkt in principe het zelfde, alleen daar moeten we het return-type van de DeSerialize method casten naar in dit geval “UserSettings”. Zie de volgende listing:

Typecasten, de compiler vertellen dat de in dit geval generieke (object) return waarde van Deserialize gebruikt moet worden als een UserSettings object dat doe je in VO.Net dus anders als in de 32-bits versie. Ik gebruik hier de Conversion Operator zoals die in de VO.Net help wordt geintroduceerd. De traditionele VO manier: type( expressie ) wordt nog wel vanwege compatibiteit ondersteund maar slechts voor de ingebouwde types als INT, WORD en dergelijke. Lees het artikel in de VO.Net help voor meer informatie over dt onderwerp.

Naar hard-disk, maar waar?

Nu we een eenvoudige methode hebben om onze informatie op te slaan als (xml)bestand is de volgende uitdaging na te denken over de locatie. Hier biedt het hedendaagse Windows meerdere alternatieven en zal het .Net Framework ons wederom uitkomst bieden om het juiste alternatief gemakkelijk te benaderen en vinden.

De Application class heeft verscheidene interessante properties voor dit doel;

·          Application.UserAppDataPath geeft een path dat verwijst naar de de applicationdata locatie voor de huidige ingelogde gebruiker. Zal ook verwijzen naar het path op server indien sprake is van een ‘Roaming User’. Wat mij betreft een bij uitstek geschikte plek om gebruikersinstellingen op te slaan. Het pad bevat ook produktnaam en versie, dit afhankelijk van de versie resource in de applicatie. Hier een voorbeeld van zo’n waarde:

de waarde bevat hier Grafx etc. omdat in dit kleine voorbeeld programma geen version resource is opgenomen en dus die uit e VO runtime gebruikt wordt.

·          Application.LocalUserDatapath echter altijd lokaal op het huidige systeem, maar wel gebruiker/produkt/versie specifiek.

Andere, belangrijke property van het Application object is de CurrentCulture, hierin zit een CultureInfo object waar allerlei instellingen als taal, datumformaat en ander regionale instellingen uit opgehaald kunnen worden.

Een andere mogelijk is de Environment class, deze heeft de GetFolderPath method waarmee de verschillende systeemfolders (My Document, My Picture etc.) opgevraagd kunnen worden. (zie voor voorbeelden van Environment, Environment.prg). De Environment class kan ook gebruikt worden voor het achterhalen van de UserName, MachineName, OSVersion en een aantal andere informatieve zaken.

Voor het voorbeeld kiezen we voor het UserAppDataPath, en om daar een Filename aan te koppelen gebruiken we een andere handige .net class, de Path class. Deze class voorziet in allerlei praktische en veilige manieren om paden te bewerken. De locatie is praktisch omdat gebruikers hier natuurlijk altijd rechten hebben.

Het schrijven zal er dan zo uitzien:

Een andere manier om gebruiker specifieke informatie op te slaan die Duncan noemt in zijn artikel is Isolated Storage. Dit is een specifiek door het .net framework ondersteunde manier van bestanden opslaan die vanuit beveiligingsoogpunt gezien nog veiliger is. Een applicatie kan namelijk misschien helemaal geen recht hebben op het schrijven in het Filesysteem, maar schrijven naar Isolated storage mag dan wel, default mag zelfs een applicatie die van een internetsite gedownload of gestart wordt daar schrijven. Een soort van sandbox-omgeving dus. Deze functionaliteit wordt ondersteund door de framework class IsolatedStorageFile.

Al met al geeft dit voldoende flexibele mogelijkheden om met enkele regels code settings in te lezen en weg te schrijven, het enige dat je zelf hoeft te doen is keuzes maken met betrekking tot de locatie en het moment waarop.

Wat hebben we nu allemaal geleerd uit dit artikel?

·          Hoe .net omgaat met configuratiefiles, hoe je ze maakt en waar je ze opslaat.

·          Dat je er van uit moet gaan dat bijna alles al aanwezig is in het .Net Framework.

·          Dat je door over te stappen naar .net je eigen codebase sterk kunt verkleinen.

·          Dat het verstandig is door je eigen bibliotheek te lopen en per module te kijken welke .net framework classes de plaats van die modules kunnen innemen.

·          Dat je dus meer tijd overhoudt om echte functionaliteit te bouwen.

·          Hoe je objecten gemakkelijk kunt persisteren naar bestanden.

·          Dat security en rechten een belangrijke rol gaan spelen voor ontwikkelaars en dat het tijd wordt dat je daar rekening mee gaat houden (vaak is dat automatisch zo als je .net classes gebruikt).

·          Hoe je types kunt opvragen en moet casten in VO.Net.

·          Dat je config-files gewoon met Notepad kunt bewerken, tenminste als je daar rechten toe hebt.

·          Dat je van .net artikelen en sessies enorm veel kunt leren en dat dat allemaal direct bruikbaar is in VO.Net.

·          Dat .Net ook voor Visual Objects ontwikkelaars een grote stap vooruit is.

Wil je ook met VO.Net aan de slag? VOPS subscribers beschikken over de VO.Net omgeving en kunnen vandaag al dit soort code schrijven.

Ed Richard