Bedste bog om udvikling og metode nogensinde?

Har netop afsluttet: Practices of an Agile Developer af Venkat Subramaniam og Andy Hunt.

Det er for mig at se den bedste bog man kan forestille sig om udvikling og udviklingsmetoder.

Så hvis du er interesseret i agile udvikling, så smid alt hvad du har i hænderne og løb ud og køb et eksemplar. Den er hurtigt læst (178 s.) og kan måske ændre dit liv ;-)

Sikker konvertering af en SecureString til en krypteret string?

Hvis du, som jeg, er i den situation, at du har brug for at gemme en SecureString mellem brugersessioner, da er du en smule på spanden...

Følg derfor min tråd i gruppen microsoft.public.dotnet.security, hvor vi bl.a. diskuterer hvorledes man på en sikker måde kan konvertere en SecureString til en krypteret string:

http://groups.google.com/group/microsoft.public.dotnet.security/browse_thread/thread/39caffb48c75e25f/4d2972a0ca45eebb#4d2972a0ca45eebb

Super guide til TFS

Jeg vil gerne gøre opmærksom på, at Patterns & Practices har lavet en fantastisk guide i brugen af Visual Studio Team Foundation Server (TFS). Guiden er p.t. i beta, men den er absolut brugbar og kan spare dig masser af tid.

Du kan downloade guiden fra Codeplex:

http://www.codeplex.com/TFSGuide

Guiden viser hvordan man får mest muligt ud af TFS gennem en samling best practices og how-to's. Der interessante bl.a. tips om

• projektstruktur,
• brugen af branching og merging,
• kontinuerlig build,
• vedligehold af project templates

og meget mere.

Jeg havde, i al beskedenhed, planlagt at lave noget lignende selv. I al fald en samling af mine erfaringer med TFS, men Patterns & Practices er i den grad kommet mig i forkøbet, med et letlæseligt og overskueligt dokument, der samler en masse erfaringer med TFS.

Indsæt de nødvendige using-statements automatisk vha. VS2005

Under læsning af ”Programming Microsoft® Visual C#® 2005: The Language” blev jeg for første gang klar over, at VS2005 kan hjælpe med at indsætte de nødvendige using-statements i koden. Siden glemte jeg genvejen, og kunne ikke finde den igen. Nu er jeg faldet over den igen, og jeg synes det er så smart at jeg hellere få det skrevet ned.

Når du får fejlen “The type or namespace name 'XXX' could not be found (are you missing a using directive or an assembly reference?)” navigerer du blot til fejlen og trykker Shift-Alt-F10. Herved fremkommer en menu med mulighed for enten at indsætte de using-statements der kan løse problemet, eller prefikse den benyttede type med det fulde namespace:

Alternativt til at benytte Shift-Alt-F10 kan du højreklikke på fejlen og vælge menupunktet resolve:

Ovenstående fungerer imidlertid kun ved erklæring af variable, ikke ved fx kald til klassemetoder.

Bemærk, Shift-Alt-F10 er også genvej til smart tag menuen, fx til implementation af interfaces.

Check-in policies (4 af 4) - Testing Policies

Ved hjælp af policy typen Testing Policy kan man sikre, at udvalgte tests kan eksekvere uden fejl på den kode man ønsker at checke ind. Jeg gennemgår her det relativt avancerede tilfælde hvor et team projekt består af flere solutions med forskellige testing policies. I den forbindelse benytter jeg Custom Path Policy fra Team Foundation Server Power Tool i kombination med Testing Policy.

Visual Studio Test Metadata fil

Før du kan tilknytte en testing policy til dit teamprojekt må du oprette en Visual Studio Test Metadata fil som beskriver hvilke unittests der potentielt kan indgå i din testing policy.

I VS2005 vælger du under menupunktet Testà Windows à Test Manager:

Herved fremkommer Test Manager vinduet. Højreklik på List of Tests for at tilføje en ny test liste:

Angiv Testlistens navn og en evt. beskrivelse:

Vælg OK og træk herefter de tests du ønsker skal indgå i denne testliste fra mappen All Loaded Tests til den nye testliste.

Tilføj Testing Policy

I Source Control Settings skærmbilledet (se Etablering af check-in policies) trykker du på knappen Add, for at få følgende vindue frem:

Vælg Testing Policy og tryk OK.

Tryk på Browse:

Naviger til den relevante Visual Studio Test Metadata fil:

Tryk OK, du ser nu et skærmbillede i stil med:

Heri vælger du den eller de testlister som du ønsker der skal checkes af denne policy:

Tryk OK for at returnere til Source Control Settings skærmbilledet:

Bemærk, at som der laves flere unittests kan disse fx tilføjes den relevante testliste, hvis de ønskes undersøgt ved check-in.

Testing Policies mod flere solutions

Hvis du som jeg har flere solutions i dit team projekt, kan du tilføje yderligere Test Policies som beskrevet ovenfor. Resultatet bliver flere Test Policies i Source Control Settings skærmbilledet:

Flere Test Policies mod forskellige solutions giver imidlertid problemer, idet check-in af ændringer i solution A, betinges både af den testing policy der hører til solution A, men også af den testing policy der hører til solution B. Og omvendt.

Vi har altså ved behov for at kunne styre for hvilken solution vores testing policy gælder.

En simpel løsning på dette problem findes i policy typen Custom Path Policy, som installeres med Team Foundation Server Power Tool. Bemærk det kan være nødvendigt også at
installere Domain-Specific Language Tools for Visual Studio 2005.

Custom Path Policy fungerer sammen med en eksisterende check-in policy (i vores tilfælde en Testing Policy). Den lader dig specificere en eller flere source control paths som den tilknyttede policy skal fungere imod.

Tryk i Source Control Settings skærmbilledet på knappen Add. Når Team Foundation Server Power Tool er installeret har du en række nye Check-in policy typer at vælge imellem. Vælg Custom Path Policy og tryk OK:

Du skal nu udpege den tilknyttede (Child) policy. I drop down’en vælger du den relevante testing policy. Bemærk policies af samme type er svære at se forskel på, idet de blot nummereres fortløbende i henhold til listen på Source Control Settings skærmbilledet:

Jeg ønsker denne testing policy anvendt på alt under source control path’en:

$/FagCentrum/FagCentrumV2/Forbundet.Tools.Validation/

Hvilket svarer til stier som opfylder det regulære udtryk:

^\$/FagCentrum/FagCentrumV2/Forbundet.Tools.Validation/(./)*$

Indtast dit regulære udtryk i feltet Source Control Path Filter:

Tryk herefter Add:

Tryk endelig OK.

Processen herover gentages for hver testing policy.

Bemærk, at den til Custom Path Policy’en knyttede (testing) policy skal disables for at undgå at policy’en køre to gange.

Vælg derfor at disable de relevante testing policies i Source Control Settings skærmbilledet:

Hermed har vi etableret vores check-in strategi.

Check-in policies (3 af 4) - Code Analysis

I dette indlæg beskrives en en check-in policy som stiller krav om at Code Analysis skal være kørt før check in.

I Source Control Settings skærmbilledet (se Etablering af check-in policies i første
indlæg i denne serie) trykker du på knappen Add, for at få følgende vindue frem:

Hvis du ikke har installeret TFS Power Tool vil du som nævnt blot se 4 policy typer. Vælg nu policy-typen Code Analysis og tryk OK.

Du får nu mulighed for at konfigurer Code Analysis for dit team projekt:

Se MSDN-dokumentationen for detaljeret dokumentation for dette. Efter den ønskede konfiguration er på plads trykker du på OK.

Du ser nu Source Control Settings skærmbilledet igen:

Vælg OK for at afslutte processen.

For at få den konfigurerede Team Project Code Analysis policy anvendt på projekterne i de enkelte solutions, højreklikker du på din(e) solution(s) i Solution Explorer og vælger Migrate Code Analysis Policy Settings to Solution:

Hvis du nu forsøger check-in af ændringer uden først manuelt at have kørt code analysis får du fejlen:

Bemærk, det er ikke nødvendigt med en fejlfri code analysis for at kunne foretage check-in. Reglen sikre blot at du har kørt code analysis på de seneste ændringer og forhåbentligt forholdt dig til resultatet.

Check-in policies (2 af 4) - Work Items

I dette indlæg beskrives en en check-in policy som kræver at enhver ændring i koden associeres med work items ved check in.

I Source Control Settings skærmbilledet (se Etablering af check-in policies i første indlæg i denne serie) trykker du på knappen Add, for at få følgende vindue frem:

Hvis du ikke har installeret TFS Power Tool vil du blot se 4 forskellige policy typer. Vælg nu policy-typen Work Items og tryk OK.

Du ser nu Source Control Settings skærmbilledet igen:

Vælg OK for at afslutte processen.

Hvis du nu forsøger at checke kode ind uden at associere ændringen med et eller flere work items vil du nu få fejlmeddelelsen:

Du associerer med dine rettelser med work items ved at vælge punktet Work Items og her udvælge de relevante work Items:

Check-in policies (1 af 4)

I det indlæg beskriver jeg en relativt avanceret check-in policy eksemplificeret ved projektet FagCentrum. I Fagcentrum har vi følgende check-in policy:

1. Enhver ændring i koden associeres med work items ved check-in.


2. Code Analysis skal være kørt før check-in.


3. Koden gennemgår udvalgte tests uden fejl før check-in.

I den følgende beskrives hvorledes jeg har defineret de enkelte policies. Mht. testing policies gennemgår jeg det relativt avancerede tilfælde hvor et team projekt består af flere solutions med forskellige testing policies. I den forbindelse benytter jeg Custom Path Policy fra Team Foundation Server Power Tool i kombination med Testing Policy.

Bemærk, at du for at kunne benytte check-in policies skal være forbundet til en Team Foundation Server.

Etablering af check-in policies

Etablering af check-in policies sker ved at højreklikke på teamprojektet i Team Explorer. Her vælges Team Project Settings og endelig Source Control:

Nu fremkommer Source Control Settings skærmbilledet, hvor du vælger fanebladet Check-in Policy:

Såfremt du ikke tidligere har defineret policies for dit team projekt vil listen være tom.

I de tre følgende indlæg vil jeg forklare hvorledes de tre policies nævnt i indledningen etableres.

Velkommen

Ja, så blev det min tur til at få en blog. Jeg har egentlig pønset på det længe, hvilket flere upublicerede indlæg i skrivebordsskuffen vidner om. Alt for længe har jeg nydt godt af andres viden og løsninger på diverse problemer. Men nu skal det altså være slut med min passive snylten.

Jeg vil fremover forsøge, at bidrage med noget af alt det jeg går og finder ud, når jeg roder med ASP.NET 2.0, C# 2.0, Microsoft Visual Studio 2005, Team Foundation Server, Team Builds, Source Control, Check-in Policies, Code Analysis, Unit Tests, Load Tests, Code Coverage, Patterns & Practices fx Web Client Software Factory og Web Service Software Factory, MCPD-certificering, MSI og WIX, Agile udviklingsmetoder, MSF 4.1 Agile osv.

Velkommen til ”Gid jeg havde vidst hvad jeg ved nu”.