Category Archives: Visual Studio

Meghalt a Pex, éljen a Code Digger!

Van/volt a Microsoft Research-nek egy Pex nevű kis Visual Studio Extensionje. Automatikusan képes volt Unit teszteket generálni. Nem egyszerűen permutálta egy tesztelendő metódus paramétereit, hanem belenézett a kódjukba, kihalászta belőle a literálokat (a == 3, case “alma”, b *= 4, ezekből a 3, 4 és amát), és ezeket is felhasználva generált paramétereket a teszteléshez. Miközben futtatta a tesztelt kódot, közben profilerrel nézte mely ágakat fedte le, így addig próbálta nyúzni a kódot, míg 100%-os lefedettséget nem ért el. Null és üres string ellenőrzési hiányosságokat, túlcsordulásokat és tömb túlcímzéseket másodpercek alatt ki tudott váltani. A generált unit teszteket aztán át lehetett mozgatni a saját tesztjeink közé.
No, sajnos a Pex egyelőre meghalt, a cimboráját, a Moles-s termékesítették, ez lett a Fakes, de ő kimaradt ebből a menetből. Így ő csak VS 2010-ben futtatható, újabbakban nem.

Cserébe viszont most kiadtak egy “Pex light”-ot, ez a Code Digger.

Ugyanaz az engine van benne, mint a Pexben, csak nem generál a metódus macerálás végén unit teszteket, csak megmutatja, melyik paraméterre mit reagált.

Egy-egy kényesebb metódusra érdemes lefuttatni, tanulságos lehet.

TDD tanfolyam

OzCode

Mátyás Gergely hívta fel a figyelmem az OzCode nevű kis debugger ketyerére (utólag is köszönöm neki).

Az OzCode egy (egyelőre ingyenes) kis VS kiegészítés, ami a debuggert okosítja fel. Hogy miket tud nem írom le tételesen, a honlapján szépen összeszedték.

Amire nekem most jó volt. Elszállt az adatbázisba mentő kód.
Additional information: The incoming tabular data stream (TDS) remote procedure call (RPC) protocol stream is incorrect. Parameter 59 (“@p56”): The supplied value is not a valid instance of data type float. Check the source data for invalid values. An example of an invalid value is data of numeric type with scale greater than precision.
OR mapper generálta az insertet, így nem tudtam, mi az 56. paraméter. A Hiberna belső batch-elője szállt el, amiben a jófene tudja hol vannak a commandok és a paraméterek.
Sebaj, itt jön az OzCode. A referenciára ráállva rákerestettem a @p56-ra, erre végigkeresi az ojjektumból kiindulva a referenciákat, és meg is találta benne:

Nem csak a memberök nevére keres, hanem a változók tartalmára is, a @p56 is egy insert string belsejében volt!
Az insertet megnézve látszott, hogy ez a Fitness nevű propertyre képződik le. Feljebb menve a stacken ismét kerestettem egyet:

Gyönyörűen látszik, hogy NaN a double property értéke, ez nem tetszett az SQL Servernek, ő nem tud ilyet ábrázolni.

Barátunk az OzCode.

TDD tanfolyam

Érdekes .NET perf tapasztalat

Amikor profilerrel megnézünk egy .NET kódot sokszor megdöbbentő helyen lesz benne bottleneck.

Az alábbi kód 1% időt visz el egy nagyon processzorintenzív kódban:

if (bar.L == 0)

Ami ebben lassú, az a System.Decimal.op_Implicit(int32). A bar.L egy decimal. Érdekes, mi?
Mi a megoldás? A 0 legyen valóban decimal, de int, amit konvertálni kell:

if (bar.L == 0M)

1% kevés, de sok 1% már számít.

Visual Studio unit teszt profilozás

A unit tesztek kiváló sebességmérési célok lehetnek, mivel kimagozottan futtatnak egy adott kódrészletet. A unit teszten jobb gomb, create performace session. Zseniális, csak nem megy, ha 64 bitesre van állítva a unit teszt host. Nem láttam ledokumentálva (vagy csak nálam nem megy ez).
Egyszerűen soha nem ér véget a tesztelés, beragad a profiler session.

Sandcastle és társai

Az NDoc halott, van helyette SandCastle. Nagyon jó, imádom. Ezzel csinálják a VS doksiját is. Van még kétely valakiben?
Az is jó, hogy nem kell kézzel írnom a konfigját, mert van hozzá Sandcastle Help File Builder, ami hasonló GUI, mint az ndochoz volt.
Aztán, hogy ne kelljen sokat gépelni az xml kommenteket, ott a GhostDoc. Beépül a VS-be, és CTRL-ALT-D-vel létrehoz egy komment vázat az adott kódrészhez. Meglepően ügyesen, ha angol neveket használunk a kódban.
Mindhárom eszköz zseniális és INGYENES. Aki ezek után nem dokumentálja a kódját, annak 1-es. :)

VS Profiler nem megy Hyper-V-s gépen

Felraktam a gépemre a Hyper-V-t. A VSTS profilert akartam használni, de azt mondta, No data collected.
Szerencsére megtaláltam ezt:
VS2008 does not support profiling in virtual environments (VMWare, VPC, Hyper-V).

Ez a jelek szerint nem csak virtuális guest-ekre vonatkozik, hanem a hostra is. Kikapcsoltam a BIOS-ban a virtualizálás támogatást, és egyből elindult a profiler.

Ezentúl rebootkor el kell döntenem, guest-eket akarok futtatni, vagy profiler-ezni.

Visual Studio Team System teljesítményanalízis

A Visual Studio számomra egyik egyik legkedvesebb eszköze a Profiler. Számos cégnek oldottam már meg vele teljesítményproblémákat, amelyeket profiler nélkül sokkal nehezebb lett volna.
A profiler arra képes, hogy egy futó program belső részeinek futási idejét képes mérni. Működhet sampling módban, ilyenkor bizonyos időközönként (alapban 10 millió órajelciklusonként) belenéz a futó programba, és megnézi a verem állapotát, azaz, hogy éppen melyik metódusban van a vezérlés.
A másik mód az instrumentation, ekkor kódot injektálnak az futtatandó assembly-kbe, így belülről tudják mérni, mi-mennyi ideig futott.
A sampling nem sokat lassít a mérendő programon, de pontatlanabb, az intrumentation pontos, de nagyon sokat lassít a célprogramon.
Én első körben a sampling-et használom, ha csak ki akarom szúrni a kód leglassabb részét. Az intrumentation megmutatja azt is, hányszor hívtak meg egy metódust, azaz nem kell elvetni, csak másra való, mint a sampling.
A teljesítményhangolásban az a szép, hogy intuitíven sokszor nagyon mást optimalizálna az ember, mint a mérések alapján.

Az ábrán az látszik, hogy az idő jelentős részét a DateTime.Hour hívás viszi el. Kicsit gyanús ez, de sűrűbb mintavétellel vagy instrumentation segítségével jobban rá lehet nézni a körmére. Ha igaza van (valószínű), akkor ez pont olyan pont, amire álmomban nem gondoltam volna.

Érdemes megfigyelni még, hogy a felső toolbaron van egy láng ikon, arra kattintva a hívási fában azonnal levisznek a leglassabb metódushoz. Egyszerű, de szenzációs. Ez a 2008-ban jelent meg.

Debugolás a .NET fw. forrása segítségével

Kaptam egy igen nehezen megközelíthető problémát, amelyben a fókusz a TAB-ra átlépett egyes controlokat. Nem egy triviális TabStop=false probléma volt.
VS 2005-ös projektekről van szó, átkonvertáltam őket 2008-ra, hogy tudjam a fw. forráskódját is debugolni. Az _NT_SYMBOL_PATH= nekem be van állítva a gépen a publikus os szimbólumokra (elsősorban ahhoz amikor WinDbgozok), emiatt nem tudtam a vsből .net fw.-öt debugolni, mert előbb lehúzza a stripped szimbólumokat, a teljeshez már hozzá se nyúl. Ezért egy bat-ból indítom a vs-t, előtte kiütve az eredeti _NT_SYMBOL_PATH-t.
Így már ment a fw. forrás debug, de mivel a clr az ngenelt optimalizált kódot töltötte be, ezért nagyon sok típus belseje nem látszik normálisan. Erre megoldás itt található. Le lehet tiltani, hogy a CLR az ngenelt kódot töltse be, így már rendesen lehet debugolni.
Lehetne, ha nem lenne elcsúszva némelyik forráskód a pdb-ben található sorszámoktól. Ilyenkor van az, hogy teljesen más sorokon lépkedünk végig, mint amit a source ablakban látunk, pl. kommenteken lépked végig a debugger.
A megoldás erre egyszerűbb volt, mint gondoltam volna: próbaképpen kitöröltem 3 sort pl. a Control.cs elejéből, így visszaállt a szinkron.
Maga az alapprobléma egyébként abból adódott, hogy egy kompozit Third Party Contol explicit letiltotta
a TAB-olást, a ControlStyle-ból kivéve a Selectable flaget.

Elegáns Powershell script XML feldolgozásra

Az itt látható példa azokat a C# kódfájlokat listázza ki, amelyek árván maradtak, azaz ott vannak a fájlrendszerben, de nincsenek benne egy csproj fájlban.
Az egész számomra azért érdekes, mert szerintem igen tömören és elegánsan parsolják az xml csproj fájlt Powershellel.
A lopás árnyékát el nem kerülve, de idemásolom a példát a fenti forrástól:

param([string]$csproj = $(throw 'csproj file is required'))

$csproj = Resolve-Path $csproj
$dir = Split-Path $csproj

# get the files that are included in compilation
$xml = (Get-Content $csproj)
$files_from_csproj = $xml.project.itemgroup | 
	%{ $_.Compile } | 
	%{ $_.Include } |
	?{ $_ } | 
	%{ Join-Path $dir $_ } |
	Sort-Object

# get the files from the dir
$files_from_dir = Get-ChildItem $dir -Recurse -Filter *.cs |
	%{ $_.FullName } |
	Sort-Object
	
Compare-Object $files_from_csproj $files_from_dir

VS 2008 SP1 telepítési tapasztalatok

Tegnap megjelent a VS 2008 SP1, korábban hiányoltam.
Előtte le kellett futtatni a VS beta dirib-darabokat leszedő eszközt, a Visual Studio 2008 Service Pack Preparation Tool-t.
A takarító cucc elszállt, annak rendje és módja szerint, a Team Foundation Explorer matatása közben. Megpróbáltam repair-elni azt az eredeti DVD-ről, ugyanazzal a hibával elszállt. A logban láttam, hogy valamit akar a G: drive-ról, annak idején erről telepítettem, de most nem arról akartam repair-elni. Berakom a G:-be a DVD-t, és a repair sikeres. Most emlegetem a telepítő-írót kicsit. :)
A removal tool ezek után már simán működik persze, mehet az SP telepítő. A mostanában szokásos webes telepítőről van szó, ami pici, de aztán lehúzza magára az univerzumot. Érdekes, hogy egyszerre elindítottam egy X64-es és egy X86-os gépen is, és az X64-en vagy 3x annyi letöltési időt ír ki, hiába, hosszabb adat- és címbusz, hosszabb kód.
A telepítés nem kapkodja el, jó 1.5 órát elmolyolt, de felment. Kíváncsi vagyok a korábbi heap probléma előjön-e ezzel a végleges fw-kel.