Category Archives: Development Tools

PerfView – ladění v 64-bit prostředí – NGen

Zanechat odpověď

PerfView je zajímavý nástroj od Microsoftu, který umožňuje neinvazivní profiling stroje, např. produkčního serveru, tím, že se přihlásí k odběru ETW událostí Windows.

Nevýhodou je, že .NET call-stacky jsou nepoužitelné, pokud profilujeme 64-bit .NET process.

Pomoci se tomu dá zkompilováním assembly/-ies pomocí NGenu:

D:\WebApp\bin>"C:\Windows\Microsoft.NET\Framework64\v4.0.30319\ngen" install MyAssembly.dll /nodependencies /verbose

…NGenovat je potřeba všechny assembly, které nás ve vyhodnocení call-stacku zajímají.

U webového kontextu je potřeba recyklovat AppPool.

Pokud by NGen hlásil chybějící dependencies, lze to dohledat pomocí FusLogVw.exe.

Visual Studio: *.sqlproj is not supported by this version of application

Zanechat odpověď

Při otevírání solution ve Visual Studiu (2010 i 2012) s databázovým projektem (myšleno *.sqlproj) se zobrazuje hláška, že projekt nelze otevřít, protože není podporován aplikací.

Z SQL Serveru je třeba doinstalovat komponentu SQL Server Data Tools.

Instaloval jsem z SQL Serveru 2012, při příštím otevření Visual Studia se mi zobrazila nabídka ke stažení a instalace SQL Server Data Tools z internetu, kterou bylo třeba provést (a vypnout VS, jinak instalace neprojde).

Poté již lze pracovat se *.sqlproj projekty.

„StanPackage package did not load correctly“ při porovnání souborů ve Visual Studiu 2012

Zanechat odpověď

Stačí jednou otevřít (a zase zavřít) okno View – Other Windows – Code Analysis.

UPDATE: Problém se po pár týdnech vrátil. Zdá se, že problém způsobovala jedna z verzí Code Contracts, provedl jsem reinstalaci (repair) Visual Studia a reinstalaci Code Contracts na nejnovější verzi, problém opět zmizel.

Diff Visual Studio 11 z příkazové řádky + použití s TortoiseSVN

Zanechat odpověď

Krásný nový Diff-tool z Visual Studio 11 se dá vyvolávat i externě z příkazové řádky a dá se tak použít například i přímo z TortoiseSVN.

Obecná syntaxe je:

devenv /diff sourceFile targetFile [sourceDisplayName] [targetDisplayName]

Pokud již nějaká instance Visual Studia běží, použije se, jinak se spustí nové.

TortoiseSVN

Pro TortoiseSVN v Settings/Diff Viewer stačí přepnout na „External“ a použít:

C:\Program Files (x86)\Microsoft Visual Studio 11.0\Common7\IDE\devenv.exe /diff %base %mine %bname %yname

(Cestu si samozřejmě upravte podle sebe.)

…teď už jenom zajistit, jestli se dá takhle vyvolat i merge. Z výpisu devenv /? to zatím nevypadá.

NuGet – poznámky z přednášky

Zanechat odpověď

Pár mých poznámek z přednášky o NuGet (Package Manager ve VS od Microsoftu), které zřejmě nebudu dále zpracovávat.

(Microsoft MVP Summit 2012 Seattle)

Links

Tvorba vlastního package

  • NuGet Command Line (ke stažení přes samotný NuGet)
  • VS / New Project / Class Library
    • NuGet.exe pack <.csproj file>
      • vznikne .nupkg
      • je to zip ála .docx
    • NuGet.exe push <.nupkg file>
  • [global: AssemblyInformationVersion(„any string“)]
    • pre-release = číslo verze obsahuje podtržítko

Nastavení vlastního NuGet feedu ve VS11

  • Tools / Library Package Manager / Package Manager Settings / Package Sources
  • dá se tam nastavit FilePath, kde mám své packages
  • nebo použít package „NuGet.Server“
    • Install-Package NuGet.Server
    • stáhne SLN s jednoduchým servříkem

Code Contracts Editor Extensions – konečně contracty v Intellisense tooltipech

Zanechat odpověď

Samotné Code Contracts se díky pomalému rewritingu (a ještě pomalejší statické analýze, ale u té je to logické) v praxi stávaly problémem, kdy nejeden vývojář pochyboval, jestli je ochoten obětovat své pohodlí rychlosti buildů na oltář Code Contractů.

Microsoft konečně přichází s dalším logickým krokem, na který všichni tak dlouho čekají, a který by mohl pomyslné váhy opět lehce převážit ve prospěch Code Contracts – po instalaci Code Contracts Editor Extensions (doplňku do Visual Studia 2010) se Vám contracty budou zobrazovat v tooltipových nápovědách IntelliSense.

Windows Live Sync (ex-Mesh): Synchronizace nastavení Visual Studia, ale i Office (Outlook podpisů, auto-correct, atp.)

Zanechat odpověď

Poměrně krátce si hraju s Windows Live Sync Beta (dříve Live Mesh) a už mě zaujali dvě příjemné možnosti:

  • synchronizace Office-nastavení – včetně Outlook podpisů, nastavení auto-correct options a dalších věcí, které mě vždy vytáčí do běla, že je musím znovu a znovu nastavovat na čistých instalacích. Synchronizace Office je ve Windows Live Sync vestavěná, stačí ji jen zapnout
  • synchronizace nastavení Visual Studia – stačí použít synchronizaci souborů – nastavení Visual Studia se ukládá do souboru, který určíte v Options / Import and Export Settings / Automatically save my settings to this file: […]. Nasměrujte si soubor do samostatné složky a tu synchronizujte mezi počítači.

Live Sync Beta mi přijde nějaká chudší, než byl Mesh, ale svůj účel snad splní stejně a možná časem i lépe.

VS2010 – Lokalizace do češtiny ke stažení

Zanechat odpověď

V rámci snahy o zpřístupnění vývojářských nástrojům „širokým masám“ uvedl dnes Microsoft další ztřeštěnost -Jazykovou sadu pro češtinu, která Vám umožní přepnout prostředí Visual Studia 2010 Professional do češtiny. Lokalizační sada je ke stažení ze stránek MSDN.cz.

Tož přeji hodně štěstí těm, co se při svém prvním sestavení řešení (build solution) dostanou až k sestavení (assembly). Osobně odmítám komunikovat s kýmkoliv, kdo by na mě zkoušel tento kryptojazyk použít a důrazně vyzývám všechny, aby si před komunikací se mnou zjistili anglickou podobu, chtějí-li se vyhnout mému podezření, že jsou marťani.

Osobně mi jako výrazně lepší nápad pro jazykově méně vybavené přišel nástroj CLIP (Captions Language Interface Pack) pro VS2008, který zobrazoval překlady až na najetí myši na danou část UI.

Notes on VS2010 Advanced Debugging

Zanechat odpověď

Koukám na zajímavou session (sérii) na téma Techniques on Advanced Debugging a nedá mi to, abych si z toho neudělal pár „účastnických“ poznámek pro mé kolegy. No a když už si je píšu, tak je dávám k dispozici, třeba to někomu přijde vhod:

Doporučuje se
  • Vypnout přepínač „Just my code“ v Options/Debugging (umožní ladit i Release code a spoustu dalších věcí, které jinak nejsou možný)
  • Vypnout přepínač „Enable the Visual Studio hosting process“ (= MyApp.vshost.exe, slouží ke zrychlení zavádení procesu, ale má i nepříjemné side effecty)
Triky
  • pomocí Open Project/Solution se dá otevřít .EXE (!!) soubor a následně ho debuggovat (až už F5 nebo Attach to process)
    • chce to mít .PDB soubory symbolů
    • v Properties od solution se dá nastavit v Debug Source Files, kde jsou zdrojáky, pokud nenastavím a nenajde je v původní cestě dle PDB souboru, tak se zeptá na cestu během ladění (pokud mu ji nedám, udělá disassembly do MSIL)
  • v Call Stacku lze nastavit Break Point (F9), který se nastaví při návratu na dané místo
  • lze nastavit Break Pointy pouze na některou část řádku (např. v cyklech for/foreach/do-while zvlášť na vstup do cyklu, zvlášť na inicializaci, zvlášť na vyhodnocení podmínek, atp.); stačí pravým/F9 kliknout na danou část řádku a vložit BP tam
  • Pokud dělám in-line watch (data tip) a zobrazené hodnoty mi překrývají kód, který chci vidět, stačí zmáčknout Ctrl a dokud ho držím, potom watch-box zprůhlední
  • v in-line watch-boxu (data tip) se dá pravým tlačítkem vyvolat contextové menu a třeba tak přidávat do Watch Window zanořená pole, která chci sledovat
  • v in-line watch-boxu (data tip) se dají hodnoty editovat (měnit za běhu hodnoty proměnných), stejnětak ve Watch panelu 
  • do Watch Window se dají přidávat řádky (výrazy) drag&dropem z kódu
  • v Immediate Window se dá během přerušení debuggeru spouštět vlastní kód, vyhodnocovat metody, atp., zahájíme-li řádek otazníkem, dostáváme hodnotu výrazu
  • Make Object ID (pravým na data tip/watch) – objekt dostává referenční číslo (např. „1#“) a je pak možné sledovat jeho hodnotu i mimo původní scope viditelnosti a třeba udělat i instanční podmínku „this == 1#“ do Breakpoint Condition, nebo se dozvědět o tom, že byl garbage-collected (stále observuji určitou referenci v paměti, něco jako WeakReference)
  • ve Watch Window můžu používat pseudo-variables
    • $user – aktuální identita threadu + processu
    • $exception – aktuální výjimka
  • Set Next Statement – pokud debuguji, tak mi žlutě svítí řádek, který se má jako další vykonat, vlevo od něj je žlutá šipka, pokud tuhle šipku přetáhnu na jiný řádek, přesune se mi vykonávaný kód tam (aniž by mezi tím bylo cokoliv spuštěno, prostě takový jump do neznáma, obvykle se může hodit, pokud chceme něco přeskočit); skákat se dá nejenom dopředu, ale i dozadu
  • Remote Debugging je stále omezen na tutéž doménu nebo two-way trust
Tipy
  • pokud Visual Studio dělá ptákoviny, padá na určitém projektu, nechce ho debuggovat, nebo ignoruje Break Pointy, potom stojí za zkoušku smazat (nebo alespoň na zkoušku někam přesunout) soubor .suo (uživateské nastavení solution, hidden file ve stejné složce jako .sln), nemusí to být ono, ale občas se stane, že se tenhle soubor poruší a pak se může dít výše uvedené (nejdřív samozřejmě zkusit restart VS, popř. PC)

MSBuild na x64 nepracuje správně s Code Contracts + how to fix (Updated)

Zanechat odpověď

Máte-li samostatný build-server na x64 platformě, na něm nainstalované Code Contracts a pouštíte 64-bitový MSBuild, potom rychle zjistíte, že takový build ignoruje Code Contracts.

Problém je v tom, že do msbuildu se nanaimportují targets pro Code Contracts (C:\Program Files (x86)\Microsoft\Contracts\MsBuild\v3.5\Microsoft.CodeContracts.targets), protože Code Contracts se nainstalují do „Program Files (x86)“ složky, kdežto 64-bitový MSBuild si nastaví property MSBuildExtensionsPath na „Program Files“ a tam Code Contracts nainstalované nejsou.

Microsoft.CodeContracts.targets se dostávají do MSBuildu přes Custom.After.Microsoft.Common.targets, které se linkují z Microsoft.Common.targets – tam je však cesta k nim sestavena přes property MSBuildExtensionsPath a ta má pro 64-bitový MSBuild hodnotu „C:\Program Files\MSBuild\“ a ne „C:\Program Files (x86)\MSBuild\“.

Problém se dá vyřešit buď používáním 32-bitového MSBuildu, nebo násilným přepsáním hodnoty MSBuildExtensionsPath na „C:\Program Files (x86)\MSBuild\“ v souboru c:\Windows\Microsoft.NET\Framework64\v3.5\Microsoft.CodeContracts.targets takto: 

<PropertyGroup>

    <!-- HAVIT: Workaround oprava ConnectID 109232 -->
    <MSBuildExtensionsPath>C:\Program Files (x86)\MSBuild\</MSBuildExtensionsPath>
    <!-- HAVIT: end -->

<CustomBeforeMicrosoftCommonTargets Condition="'$(CustomBeforeMicrosoftCommonTargets)'==''">$(MSBuildExtensionsPath)\v3.5\Custom.Before.Microsoft.Common.targets</CustomBeforeMicrosoftCommonTargets>
<CustomAfterMicrosoftCommonTargets Condition="'$(CustomAfterMicrosoftCommonTargets)'==''">$(MSBuildExtensionsPath)\v3.5\Custom.After.Microsoft.Common.targets</CustomAfterMicrosoftCommonTargets>
<ReportingServicesTargets Condition="'$(ReportingServicesTargets)'==''">$(MSBuildExtensionsPath)\Microsoft\VisualStudio\v9.0\ReportingServices\Microsoft.ReportingServices.targets</ReportingServicesTargets>
</PropertyGroup>

Problém samozřejmě může nastat, až jiné build-extense než Code Contracts použijí C:\Program Files\MSBuild\ a celé se to rozjede.

Dle hlášeného bugu na Connectu však stejný problém je i s WCF, takže si myslím, že soudruzi v Microsoftu někde přecijenom dělají chybu.

Web Deployment Project + Update

Prakticky identický problém jsem řešil s beta verzí Web Deployment Projectu pro VS2010, nakonec jsem se vykašlal na úpravy souborů a prostě jsem sesynchronizoval obsah C:\Program Files\MSBuild\ se složkou C:\Program Files (x86)\MSBuild (překopíroval jsem jedno přes druhé a vice versa).

Nyní s vydáním RTW verze Web Deployment Projectu jsem si všimnul, že je toto již řešeno použitím propert $(MSBuildExtensionsPath32), která vede do správného místa. V Code Contracts by tedy mělo stačit změnit „všechny“ $(MSBuildExtensionsPath) na $(MSBuildExtensionsPath32), ale nezkoušel jsem to zatím.