Slides a dema z mé přednášky pro konferenci Gopas ShowIT Bratislava z 10.2.2016:
Záznam z přednášky je publikován na našem HAVIT YouTube Channel.
Dotčená témata
Pomocí analyzérů ve VS 2015 máme možnost kontrolovat programový kód různými pravidly ověřující štábní kulturu kódu. Netestuje se tedy, zda kód dělá to, co má, ale zejména to, jak je zapsán. Ale i to dokáže občas odhalit chyby v chování programu.
V aplikacích je však nejen kód ručně psaný programátory, ale často i kód generovaný různými nástroji (designer soubory od resources, aspx, atp.)
Takový kód často nesplňuje pravidla, které na vlastní kód klademe, a zároveň nemáme možnost způsob generování ovlivnit.
Jedno možností je použít global suppressions (viz Code Analysis na stránce https://www.visualstudio.com/en-us/news/vs2015-update1-vs.aspx), druhou možností je vypnout kontrolu generovaného kódu ve vlastnostech projektu.
To však přináší zmatek v tom, co který analyzér považuje za generovaný kód. Pro určení, zda jde o generovaný kód používají různé nástroje různé techniky, například
Jako generovaný kód označují kód souboru (zdroj):
Jako generovaný kód označují kód (zdroj):
Neobsahují žádnou logiku pro odlišení generovaných souborů od ostatních (nebo se mi ji alespoň v čase, který jsem hledání byl ochoten věnovat, žádnou nenašel).
(zdroj)
Tabulka ukazuje, které analyzéry považují jaký soubor za generovaný (ano = generovaný, ne = nerozpoznáno):
| .designer.cs (název souboru) |
// <auto-generated> (obsah souboru) |
[GeneratedCode] (obsah souboru) |
|
| Code Analyzers | ne | ne | ne |
| StyleCop Analyzers | ano | ano | ne |
| Sonar Lint | ano | ano | ano |
Pokud ve Visual Studiu editujete XML soubory, ke kterým máte XSD schema, můžete se dočkat hlášek typu:
Potíž je v tom, že Visual Studio se snaží schema XML souboru validovat vůči XSD souborům z celé solution (dle namespace). Pokud máte tedy odpovídající XSD soubor v solution vícekrát, výsledkem jsou výše uvedené kolize.
Zbyněk Řešetka (děkuji) mě nasměroval na původní správné řešení, o kterém jsem si myslel, že ve VS2015 zmizelo – dialog XML Schemas, kde si aktivní schema navolíte, i když máte XSD soubor v solution vícekrát:
Přístupný je přes menu XML / Schemas… Záludnost, která mě zmátla, spočívá v tom, že toto menu existuje pouze pokud je otevřen XML soubor a nastavení schemat se nedá vyloudit ani přes Quick Launch.
Slides a dema z mé přednášky pro konferenci MS Fest Praha z 29.11.2015.
Záznam je publikován na našem HAVIT YouTube Channelu:
Dotčená témata
WinDbg (Windows Debugger) má svá specifika. Představuji si to asi tak, že když už byl příslušný tým v Microsoftu po několika marných pokusech dotlačen k vytvoření GUI nad konzolovou podobou (jedinou pravověrnou), rozhodl se to udělat tak, aby vzniklá GUI nadstavba opravdu nikoho nelákala se do debuggingu na této nízké úrovni pokoušet.
Jedním ze specifik tak například je, že zatímco v každé jiné aplikaci pokud změníte velikost písma a podobné volby UI, pamatuje si to aplikace i do příštího spuštění, aniž byste to museli nějak řešit.
Ve WinDbg tomu tak není.
Dlouho jsem si dokonce myslel, že to nějak souvisí s novými vymoženostmi ve Windows ála UAC, které nedovolí zastaralému WinDbg uložit nastavení do Program Files nebo nějakého jiného chráněného místa, kam si natavení chce persistovat.
Není tomu tak.
Windows Debugger totiž má logiku svojí – konkrétní nastavení UI je zabaleno do podoby Workspace (mimo fontu je tam i layout oken a spousta dalších věcí). Workspaces můžeme mít více a můžeme mezi nimi přepínat (mimochodem VS2015 přišlo s layouty, implementováno však příčetněji).
Záludnost je v tom, že výchozí nastavení WinDbg má vypnuté ukládání změn Workspace. Tedy cokoliv nastavíme, tak se vypnutím WinDbg zapomene, aniž by se to na cokoliv zeptalo. Mám dokonce pocit, že toto se v průběhu verzí muselo změnit, protože kdysi se mě WinDbg při ukončování na změnu Workspace ptal.
Změna se kupodivu projeví i v X64 i X86 verzi WinDbg.
…mno, jak jednoduché, už nebudu muset s každým spuštěním znovu nastavovat font přiměřený své slepotě, resp. vhodný pro prezentaci.
Pokud používáte snippet „ctor“ pro vytváření konstruktorů tříd, může vás štvát, že kurzor po jeho rozbalení skončí připraven v těle konstruktoru a nikoliv v místě pro zadávání parametrů.
Drtivá většina constructorů v dnešní době stejně pouze přebírá hodnoty parametrů, které uloží do lokálních privátních fieldů. Často readonly, většinou jako dependencies v patternu Constructor Injection z rodiny Dependency Injection. Takové konstruktory se poměrně efektivně vytvářejí s použitím akce „Introduce and initialize field“ na zapsaném parametru (ať už za použití Resharperu, nebo Introduce and initialize field extension).
Chceme-li změnit pozici kurzoru, stačí upravit snippet ctor a umístit marker $end$ na místo, kde chceme kurzor připravit.
Pokud máme Resharper, dostaneme se na editaci snippetu přes menu Resharper ~ Tools ~ Templates Explorer. Vybereme scope C# a editujeme „ctor“:
public $classname$ ($END$)
{
}
Bez Resharperu je potřeba editovat přímo soubor snippetu na disku, najdete ho v cestě C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC#\Snippets\1033\Visual C#\ctor.snippet. Je to krátké XML v kterém příslušný blok rychle najdete.
Výsledné chování je pak mnohem přímočařejší:
Pokud se s touto chybou potkáte ve Visual Studiu, nejspíš se vám podaří něco kolem toho vygooglit. Zákeřnější je tato chyba na TFS Build Serveru, kde jsou postupy nalezené k většinou VS irelevantní.
Obvyklou příčinou je, že se vám na Build serveru spouští při testech něco víc, než plánujete.
Například
Problém: Na build serveru (TFS 2015) spouštíme v rámci buildu unit testy. Testy jsou spouštěny vzdáleně na test serveru (test controller / test agent). Spuštění testů se nezdaří, dostáváme chybu „Failed to queue test run ‚…‘: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond.“
Řešení: Ve Windows Firewallu stroje, který vzdáleně spouště testy, povolit komunikaci programu C:\ProgramFiles (x86)\Microsoft Visual Studio 14.0\Common7\IDE\MSTest.exe.
Zdůrazňuji, že konfigurujeme volající stranu (build server), nikoliv volanou stranu (test server).
Zdá se, že nám výskyt tohoto problému souvisí s instalací Visual Studia 2015. Instalátor sice do firewallu několik pravidel přidal, nicméně ta nedostačovala.
Ač jsem dříve pracoval s více monitory, opustil jsem takový setup a po dlouhých rocích s 24″ 1920x1200px jsem dnes přešel (zatím „na zkoušku“) na 32″ panel 2560x1440px (Samsung S32D850T).
Rázem se ukázalo, že přechod mezi zadockovaným notebookem a jeho vlastním 1920×1080 nebude bezbolestný jako dosud, že uspořádání Visual Studia už bude potřeba nějak přepínat.
Pro starší verze VS byl potřeba doplněk, např. Layouts O Rama, ve Visual Studio 2015 je již vestavěno:
…synchronizuje se dokonce přes Microsoft Account, není již co řešit.
VS2015 Update: Úplně stejně se mi chovalo VS2015 pro defaultní „Web Development (Code Only)“ sadu nastavení. Níže uvedený postup pomohl.
Nějakou shodou okolností mi Visual Studio 2013 přestalo reagovat na F7 pro přechod z code-behind text-editoru na ASPX-markup editor.
V nastavení jsem zjistil, že F7 je asociováno na command View.ViewCode (Global). Stačilo přidat pro kontext Text Editor command View.ToggleDesigner.
UPDATE: VS2017 úplně stejně.
HAVIT Knowledge Base 