Category Archives: Development

.NET 4 MCP Certification Exams 70-519 (MCPD: Web) & 70-516 (TS: Accessing Data) – První dojmy z beta exams

Měl jsem příležitost zúčastnit se beta programu nových certifikačních zkoušek Microsoftu pro platformu .NET 4, nedá mi to tedy, abych se s Vámi nepodělil o první dojmy (výstup je naštěstí již značně cenzurován, za ty dva dny už jsem trochu vychladl a nepublikovatelný proud mého hodnocení dopadl jen na prvních pár lidí, které jsem potkal).

Exam 70-516: TS: Accessing Data with Microsoft .NET Framework 4

První zkouška, kterou jsem testoval, byla zkouška na datové přístupy z kategorie Technical Specialist. Dle očekávání a zaměření se jednalo o „kodérskou“ zkoušku, kde nešlo o nějaké koncepční myšlení, ale otázky směřovaly většinou na konkrétní code-snippety, nebo jiné coding techniky pro přístup k datům. V podstatě se vše točilo kolem následujících témat:

  • Entity Framework – odhadem 40%
  • LINQ, LINQ to SQL – odhadem 20%
  • pure DB Access (DbConnection, DbCommand, …) – odhadem 10%
  • „old fashion“ (DataSet, DataTable, TableAdapter, …) – odhadem 10%
  • ostatní všechno možné (XML, ADO.NET Data Services, Sync Services, konfigurace, …) – odhadem 20%

V zásadě se jedná o standardní zkoušku tohoto „kodérského“ typu, kde se opět objevilo pro mě nepochopitelné množství  otázek směřujících čistě na názvy/signatury jednotlivých metod. Něco, co v reálné praxi zcela řeší IntelliSense. Nesnáším otázky typu „Abyste udělali XY, použijete metodu: ExecuteQuery(), ExecuteQuery(true), ExecuteQuery(false) nebo ExecuteQuery<Order>()?“.
Naopak tam úplně chyběla sebemenší otázka na SqlTransactions, T-SQL, SQL-injection, apod., kteréžto znalosti bych od člověka certifikovaného na Data Access očekával (narozdíl o detailů o předávání Table Parameters nebo Spatial Data z kódu a podobných nuancí, které si každý snadno najde, když je potřebuje).
Celkové zkoušku hodnotím jako standardního následovníka dosavadních MCP kodérských zkoušek, kde Microsoft/Prometric nedokázali překonat svůj stín a místo, aby se soustředili na skutečné ověření dovedností vývojáře potřebných v každodenní praxi, tak šlo opět o koncentraci na novinky a okrajová témata, které jsou zrovna „in“. Člověk, který takovou zkoušku úspěšně absolvuje, není vůbec ověřen na základní koncepty přístupu k datům, spíše se dokázal připravit na požadavky zkoušky způsobem, který mu umožnil ji absolvovat (ať už pomocí zkušebních testů, uniklých otázek, nebo tvrdým biflováním faktů), nicméně stejně nelze úspěšně předpokládat, že by si běžný vývojář detaily, které jsou předmětem zkoušky zapamatoval déle než potřebný půlden.

Exam 70-519: Pro: Designing and Developing Web Applications Using Microsoft .NET Framework 4

Druhá zkouška, kterou jsem testoval, byla z kategorie Professional Developer pro Web Development. Zkouška by se měla zaměřovat na koncepty a znalost technologie, prakticky bez kódování. V hodnocení této zkoušky jsem bohužel mnohem radikálnější, točila se totiž celá kolem následujících témat:

  • MVC – odhadem 50%
  • ASP.NET Core Infrastructure – odhadem 25%
  • WebForms – odhadem 10%
  • Ostatní (Data Access, WCF, Silverlight, jQuery, …) – odhadem 15%

Totální zahlcení problematikou MVC mě velmi nemile překvapilo. Nikdy jsem neměl nic proti lidem, kteří se rozhodli věnovat této technologické masturbaci (dovoluji si vypůjčit trefné označení kolegy Michal Altaira Valáška), ale kdo v Microsoftu/Prometric došel k závěru, že pro testování dovedností samostatného webového vývojáře (dovedností relevantních pro běžnou praxi!), je nutné tak silně zdůraznit nové MVC a prakticky zcela opustit WebForms přístup, to mě hlava nebere.
Toto mě znechutilo natolik (a tento feedback, že by se měly oddělit zkoušky na MVC a Webforms, jsem dával do Microsoftu už dávno v dobách, kdy ještě bylo co měnit), že odsuzuji tuto zkoušku jako absolutně irelevantní vzhledem k hodnocení reálného webového vývojáře. Pokud bych měl posuzovat jeho dispozice a dovednosti pro reálnou praxi vývoje webových aplikací, tato zkouška by mi toho mnoho neřekla. Bohužel i těch několik otázek, které by tématicky patřily do podobné zkoušky, bylo položených tak, že často vůbec nesměřovaly k jádru věci, ale jednalo se např. o vyloučení zcestných odpovědí, aby zůstaly ty méně špatné. Když se Vás někdo zeptá, které dva druhy ovoce byste doporučili někomu, kdo má rád sladkosti, tak Vám z nabídky „okurky“, „igelit“, „brambory“ a „mramor“, nezbývá než zaškrtnout… (ne, bohužel tlačítko WTF testovací aplikace nenabízí a co považují autoři za správnou odpověď se můžeme jenom dohadovat).

IIS: Jaký w3wp.exe patří k jakému AppPoolu?

Na IIS6 existoval ve složce System32\ jednoduchý skript k vypsání seznamu worker-procesů a jejich příslušnosti k jednotlivým application poolům IIS:

iisapp.vbs

Na IIS7 už tento skript není, ekvivaltentní příkaz z System32\inetsrv\ však je

appcmd list wp

image

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

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.

Bezpečnostní chyba v ASP.NET a workaround s customErrors k jejímu vyřešení

V ASP.NET byla objevena (a zveřejněna!) bezpečnostní chyba, která sofistikovanějšímu útočníkovi umožní získat obsah zdrojových souborů uložených na webovém serveru, včetně web.configu. Podrobnosti popisuje ve svém blog-postu Scott Guthrie. Workaround spočívá v zapnutí customErrors bez rozlišování typu chyby.

Kdo by to chtěl vidět na vlastní oči, tak na YouTube je pěkné video.

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

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.

ASP.NET Device Filters

Nedávno se mi připomněla jedna starší lahůdka (čti obskurnost, za kterou může ten zpropadený svět heterogenních browserů) – Device Filters. Dovolím si tedy připomenout:

Jde o víceméně elegantní deklaratorní zápis, jak nastavovat různé hodnoty jednotlivých properties controlů a direktiv v ASP.NET v závislosti na browseru. Syntaxe je jednoduchá:

<asp:Label IE:Text="Používáte Internet Explorer" Mozilla:Text="Používáte Firefox" PIE:Text="Používáte Pocket IE" Text="Používáte Buchvíco" runat="server" />

Není to jen o properties controlů, dá se to použít i pro direktivy, takže například pro <%@ Page %> lze nastavit MasterPageFile či Theme. Rozpoznávané browsery se řídí browser-definition-files (App_Browsers, browserCaps).

ASP.NET Sprite and Image Optimization Framework

Že Microsoft ASP.NET team si už delší dobu hraje s věcmi kolem CSS Sprites se vědělo už dlouho. Nakonec nečekají na další release ASP.NET a uvolnili svůj ASP.NET Sprite and Image Optimization Framework už nyní (na Codeplex). Pokud tedy chcete na svých webech optimalizovat rychlost načítání a zobrazování obrázků, určitě doporučuji Vaší pozornosti. Kdo netušíte, o co jde, potom viz instruktážní video (ve zkratce jde o slučování několika obrázků do jednoho a zobrazování výřezů z něj na Vaší webové stránce pomocí CSS stylování s background-image).

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

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

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)

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.