Archive for the ‘Visual Studio’ Category

Ha a Visual Studio (2015) üresjáratban megeszik 1-2 procit…

Sunday, February 28th, 2016

akkor kapcsold ki a Git Source Control típust, mint default providert. Piszok idegesítő volt ez a hiba.

Visual Studio 2015 debugger

Wednesday, May 6th, 2015

Amellett, hogy nagyon frankón néz ki a kis chartokkal a tetején, amit kiemelnék, alul a watch ablak. Működnek a lambdák a watchban, lehet debug time linqzgatni! :)

VS2015Debugger

Meghalt a Pex, éljen a Code Digger!

Friday, March 28th, 2014

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

Wednesday, March 26th, 2014

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

Saturday, March 5th, 2011

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

Monday, May 17th, 2010

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.

Coverage fejtörő

Wednesday, May 12th, 2010

A VS coverage-e ezt mutatja, hogy ez a sor csak részben van lefedve:

return (GetSourceItem(step) – this[step – 1]) * e + this[step – 1];

Nincs benne && vagy ||, akkor triviális lenne. Én már tudom a választ. :)

Update: alul, kommentben ott a megoldás.

Disable/turn off “Attach Security Warning” in Visual Studio

Monday, May 10th, 2010

Az RC óta elfelejtettem, hát leírom magamnak.

Walkthrough: Profiling With Automated Tests

Sunday, May 9th, 2010

Egyszerű, ha tudod hol kell keresni.

VS 2010 RTM elérhető az MSDN-en

Tuesday, April 13th, 2010

És végre gyorsan jön, de lehet, hogy csak azért, mert alszanak még Amerikában.

Újabb crash hotfix a VS 2010 RC1-hez

Friday, March 5th, 2010

Itt.
Remélem ez már segít, mert már kezd az agyamra menni a a napi 10 crash.

VS 2010 RC elszállás – hotfix

Saturday, February 20th, 2010

Ez igencsak bosszantó volt, remélem a fix megoldja.
Nekem nem tablet pcm van, mégis előjön.
https://connect.microsoft.com/VisualStudio/Downloads/DownloadDetails.aspx?DownloadID=26662

Sandcastle és társai

Wednesday, September 30th, 2009

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

Monday, April 27th, 2009

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

Wednesday, January 21st, 2009

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

Thursday, December 11th, 2008

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

Tuesday, August 12th, 2008

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

Tuesday, August 12th, 2008

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.

Visual Studio Next

Thursday, May 29th, 2008

Rosario-nak hívják a drágámat, áprilisi CTP-nél járunk.
No kérem, ahogy nézem ebből a postból, az architect (kevésbé nagyképűen tervező) cuccok igen ütősek lesznek benne. Ha mást nem, hát a képeket érdemes megnézni, sokat mesélnek, mi várható.