Zojuist heb ik een klein artikel geplaatst op codeproject waarin ik een manier beschrijf hoe ik met reguliere expressies een csv-bestand omzet naar een Dataset. Hoewel er uiteraard vele manieren zijn om met csv-bestanden om te gaan, heeft deze code mij al enkele keren uit de brand geholpen.
Zojuist heb ik een klein artikel geplaatst op codeproject waarin ik een manier beschrijf hoe ik met reguliere expressies een csv-bestand omzet naar een Dataset. Hoewel er uiteraard vele manieren zijn om met csv-bestanden om te gaan, heeft deze code mij al enkele keren uit de brand geholpen.
Hoe smerig het plaatsen van business logic in je UI laag ook klinkt, er zijn momenten dat je er toch voor mag kiezen. Neem de volgende situatie:
Een website die een online hypotheekberekening aanbiedt geeft de gebruiker de mogelijkheid om met ’slider-controls’ voor eigen inkomen, inkomen van de partner en koopsom van de woning te bepalen hoe hoog de maximale hypotheek is. Door de sliders te bewegen verandert uiteraard de hoogte van het maximum hypotheekbedrag. Maar niet alleen het hypotheekbedrag wijzigt. Wanneer je je inkomen te laag zet met de slider, is het ook goed mogelijk dat de maximale koopsom wordt verlaagd.
De rekenregels die nodig zijn voor de bepaling van de samenhangende bedragen, moeten aan de cliëntzijde aanwezig zijn om een snelle UI respons te bewerkstelligen (dit wordt uiteraard makkelijker met Silverlight). Goed, dit is een prachtig moment om Script# uit de kast te halen.
Wanneer je met Script# je rekenregels hebt geschreven (middels een Script# ClassLibrary) , dan beschik je al meteen over een C# codebase. Wat is er nu mooier dan deze code te gebruiken aan de serverzijde, in je domein zelfs. Je weet meteen zeker dat je aan beide zijden dezelfde code gebruikt.
Eén van de voordelen van Script# is dat er na een compile zowel een .js-bestand als een .net assembly wordt gecreëerd.
De .net assembly ga je gebruiken in je andere projecten. Je maakt de reference, schrijft de code die de assembly consumeert en compileert… En dan ineens wordt je geconfronteerd met de melding:
The type ‘System.Object’ is defined in an assembly that is not referenced. You must add a reference to assembly sscorlib …
Je denkt dus dat je in het project waarin je de Script# .net assembly referenced een reference moet maken naar de Script# sscorlib. Op zich juist, alleen dit zal waarschijnlijk onder andere resulteren in een melding als:
The type ‘System.Reflection.AssemblyVersionAttribute’ exists in both ’sscorlib.dll’ and ‘mscorlib.dll’
En dat spreekt eigenlijk voor zich. Er zijn nu twee frameworks referenced in je project, met beide dezelfde namen voor uiteenlopende zaken (Script# is immers een port van het .net framework naar JavaScript).
Om dit snel op te lossen kan je een tweede project aanmaken voor je Script# project. maar dan met het C# ClassLibrary template. Zorg ervoor dat het gegenereerde .csprj bestand in dezelfde directory staat als het Script# project. Voeg alle .cs bestanden toe aan je C# project die ook in het Script# staan. De projecten die voorheen verwezen naar de Script# .net assembly laat je nu verwijzen naar de nieuwe C# assembly. Et voila! Twee projecten op twee verschillende frameworks, één codebase.
Voor de echte die-hard moet er natuurlijk een oplossing mogelijk zijn in het MS Build script (ofwel het .csprj bestand) om hetzelfde te bewerkstelligen. Ik hoor het graag van je….
Tijdens mijn voorbereidingen voor een presentatie over code migratie naar .Net werd door Microsoft de nieuwste versie van de Interop Forms Toolkit released. Deze toolkit stelt de ontwikkelaar onder andere in staat om gefaseerd zijn windows forms in Visual Basic om te bouwen naar .Net en deze .Net winforms uit te rollen in de VB-applicatie.
De truuk die wordt uitgehaald is dat er automagisch een COM-wrapper wordt gemaakt voor je stuk .Net-code die je vanuit je VB-app kan aanroepen. Dit heeft dus uiteraard wel als gevolg dat je je VB-applicatie moet uitrollen met het .Net-framework. Maar dat is toch de situatie waar je toe wilt….niet?
Lees meer hierover en download de toolkit op de site van Microsoft.
Voor hen die web applicaties maken is het een ondertussen bekend euvel: cross site scripting. Voorheen schreef ik zelf elke keer allerlei stukken code om te voorkomen dat dit gebeurde (een heel gedoe met encoding en decoding en het filteren met allerlei reguliere expressies). Nu (pas) heb ik de Microsoft Anti-Cross Site Scripting Library V1.5 ontdekt, en dit neemt echt veel werk uit handen.
-Download de library.
-Microsoft Anti-Cross Site Scripting Library V1.5: Protecting the Contoso Bookmark Page
Okay, ik ga er vanuit dat we allemaal nette code schrijven en op de juiste plekken try/catch blokken schrijven. In veel gevallen is het echter zo dat in het catch-deel de gevangen Exception weer opnieuw gegooid wordt. Zoals bijvoorbeeld:
try{ //doe iets dat wellicht fout gaat } catch(Exception ex){ //doe iets moois throw ex; }
Je verwacht nu dat de Exception ex die gevangen hebt, wordt gegooid. Niets is minder waar. De Exception ex wordt onder water aangepast. De stacktrace wordt opnieuw opgebouwd, met als gevolg dat je niet meer precies het regelnummer krijgt van de code die fout is gegaan, maar het regelnummer waar je de Exception hebt gegooid. Wanneer je de Exception ongewijzigd wil gooien gebruik dan :
try{ //doe iets dat wellicht fout gaat } catch(Exception ex){ //doe iets moois throw; }
Het eenvoudig weglaten van de ‘ex’ na de throw zorgt ervoor dat het Exception object ongewijzigd blijft.