Via: České kurzy zdarma na MVA!

Pri mojich prvých automatických buildoch, ktoré som mal možnosť konfigurovať, som používal NAnt. Kolega bol expert na Ant, NAnt a ostatné veci okolo projektového manažmentu a pred niekoľkým rokmi bol NAnt jediný spôsob, ako jednoducho napísať skript, ktorý skompiluje zdrojový kód, spustí unit testy, vytvorí balíček aplikácie (ZIP so súbormi webovej aplikácie, alebo spustí nástroje pre vytvorenie inštalačného balíčku) a zarchivuje výsledný build. Toto sú základné veci, ktoré sa zídu snáď na každom projekte a v dobe .NET 1.0 a 1.1 bolo v NAnt-e potrebné skriptovať kompiláciu na úrovni jednotlivých zdrojový súborov a manuálneho volania. V prípade C# projektu to znamenalo zobrať všetky .cs súbory a použiť csc.exe kompilátor, nájsť výslednú DLL/EXE assembly a niečo s ňou spraviť. Nevýhoda tohto postupu bola, že treba všetko ručne písať a Visual Studio robilo vlastnú kompiláciu podľa projektového súboru .csproj a NAnt robil druhú podľa vlastných nastavení. Bol to však vynikajúci a silný nástroj, ako celý proces zautomatizovať.

S .NET Frameworkom 2.0 prišiel systém MSBuild, ktorý sa stal základom pre kompiláciu nielen zdrojového kódu, ale celého projektu. MSBuild spracuváva projektové súbory (.csproj, .vbproj) vo formáte XML a okrem kompilovania dokáže aj spracovať resource súbory .resx, XAML súbory, digitálne podpísať assemblies a skopírovať výsledné súbory do výstupného priečinku. MSBuild obsahuje pre každý typ projektu vlastnú sadu úloh, ktoré vedia, ako správne konkrétny typ projektu spracovať. Windows aplikácie teda dokáže správne pripraviť na Click-Once nasadenie a webové aplikácie zase zabaliť do balíčku, ktorý je možné poslať na IIS a nasadiť tak aplikáciu na web. A ani poslanie tohto balíčku nemusíte robiť ručne – MSBuild obsahuje úlohu, ktorá automaticky pošle balíček na IIS server.

Visual Studio a MSBuild sú spolu integrované a preto čo zmeníte vo Visual Studiu, to sa prejaví v projektovom súbore a MSBuild ho rovnako spracuje aj pri spustení z príkazového riadku. Vývojári teda po zmene nastavení projektu môžu zmenený projektový súbor uložiť do repozitáru a keď sa na serveri spustí automatický build, tak si môžu byť istý, že bude spustený s novými nastaveniami a nemusia pracne prekonfigurovávať a prepisovať buildovacie skripty. MSBuild je súčasťou základnej inštalácie .NET Frameworku a nie je potrebné mať nainštalované Visual Studio pre jeho použitie. Toto sa však týka použitia základných úloh dostupných v MSBuild. Po nainštalovaní si Visual Studia a Windows SDK sa do MSBuild pridajú nový typy úloh, ktoré vedia pracovať s novými funkciami potrebnými pre správne zbuildovanie projektov (napr. sa nainštalujú nástroje pre kompiláciu Entity Framework súborov). Na build serveri teda je potrebné mať nainštalované Visual Studio a Windows SDK a udržiavať ich aktuálne – podľa toho, ako to vyžadujú použité funkcie v projektoch – ale integrácia s build systémami je veľmi jednoduchá, pretože na skomplikovanie projektu stačí spustiť msbuild.exe z príkazového riadku.

Priamu podporu pre MSBuild má CruiseControl.NET a aj TeamCity a samozrejme Team Foundation Server (a určite aj ďalšie systémy, ja však poznám iba tieto).

The biggest problem of all is that transactions can not span arbitrary boundaries. There are no ACID guarantees beyond a single record or small entity group. Once you wrap your head around what this means for the programmer it's not a pleasant prospect at all. References must be manually maintained. Relationships must be manually maintained. There are no cascading deletes that act correctly during a failure. Every copy of denormalized data must be manually tracked and updated taking into account the possibility of partial failures and externally visible inconsistency.

All this functionality must be written manually by you in your code. While flexibility to write your own code is great in an OLAP/map-reduce situation, declarative approaches still cover a lot of ground and make for much less brittle code.

What you gain is the ability to write huge quantities of data. What you lose is complacency. The programmer must be very aware at all times that they are dealing with a system where it costs a lot to perform distribute operations and failure can occur at anytime.

The HaaHa Show – Hacking with Phil and Scott (funguje to len v Internet Exploreri)

Všetko čo potrebujeme určiť je použitá verzia frameworku a nastaviť IIS, aby používal ASP.NET moduly.

<configuration>
  <system.web>
    <compilation debug="true" targetFramework="4.0" />
  </system.web>

  <system.webServer>
    <modules runAllManagedModulesForAllRequests="true" />
  </system.webServer>
</configuration>

Druhou novinkou je správa rôznych konfigurácii web aplikácie priamo v projekte. Doteraz bol v projekte jeden Web.config súbor, ktorý sa používal hlavne počas vývoja a pri nasadení aplikácie do produkčného prostredia bolo potrebné vytvoriť iný konfiguračný súbor a ten udržiavať samostatne. Problém bol aj s verziovaním nastavení ktoré mal každý vývojar iné. Teraz máme k dispozícii transformačné konfiguračné súbory.

Visual Studio v nových projektoch vytvorí základný Web.config súbor a k nemu dve ďalšie verzie: Web.Debug.config a Web.Release.config. Základný konfiguračný súbor sa použivá rovnako ako doteraz – nastavíte v ňom všetko potrebné pre beh webovej aplikácie. Nové Debug a Release konfiguračné súbor slúžia na popísanie zmien v ladiacej a produkčnej verzii. Ich syntax je presne taká istá ako v normálnych Web.config súboroch. Používajú však XML-Document-Transform rozšírenie, čo sú špeciálne XML atribúty, ktoré určujú, ako budú zmeny aplikované.

Transformácie XML dokumentu umožňujú pridať či odstrániť určité XML elementy a atribúty, nahradiť celý XML element úplne novým elementom, ale aj využiť XPath výrazy na definovanie podmienok, za akých má dôjsť z aplikovaniu zmi­en.

Typicky je teda v Release verzii odstránený debug="" atribút a nastavený connection string na produkčnú databázu:

<configuration xmlns:xdt="http://schemas.microsoft.com/XML-Document-Transform">
  <connectionStrings>
  <add name="MyDB"
    connectionString="Data Source=ReleaseSQLServer;Initial Catalog=MyReleaseDB;Integrated Security=True"
    xdt:Transform="SetAttributes" xdt:Locator="Match(name)"/>
  </connectionStrings>
  <system.web>
    <compilation xdt:Transform="RemoveAttributes(debug)" />
  </system.web>
</configuration>

Druhá moja požiadavka bola môžnosť upraviť si výstup tak, aby pripomínal nový MSDN Lightweight štýl – ten fialový branding MSDN knižnice. HelpStudio Lite umožňuje vytvoriť si vlastné šablóny a štýlovanie pre HTML stránky, ale aj podporné súbory pre MSHelp (index dokumentov, navigácia, atď.). Šablóny sú obyčajné HTML súbory s vloženými špeciálnymi značkami označujúci miesta, kde sa majú vložiť údaje z dokumentácie. Samotné dáta sú uložené v HelpStudio projekte – .hsp – čo je XML súbor obsahujúci celú vytvorenú dokumentáciu.

<!--DXMETADATA start type="Stylesheets" --><!--DXMETADATA end-->
<!--DXMETADATA start type="ProjectTitle" -->Project Title<!--DXMETADATA end -->

Šablóny sa v pohode dajú upravovať v editore ktorý je súčasťou HelpStudia. Ja som však využil Dreamweaver, lebo sa v ňom oveľa ľahšie čistil kód a robili štýly.

Nevýhoda Lite verzie je nutnosť výstupu iba do MSHelp 2.x verzie. HS 3 vie spraviť aj HTML výstup. Je to však také krkolomné: treba vypnúť zmazanie vygenerovaných HTML súborov. Balíčky MSHelp totiž obsahujú HTML dokumenty a HS v prvej časti kompilácie vygeneruje HTML obsah a ten v druhej fáze spojí do balíčka .HxS. S prechodom na HS 3 prišli aj trošku problémy: najprv nedokázal rozpoznať moju šablónu, pretože config.xml súbor obsahoval starú definíciu šablóny a HelpStudio ju nevie automaticky prekonvertovať. Druhý problém bol podobný. Definícia tzv. HTML Scraps je síce stále uložená v .txt súbore ale z textovej definície prešli na nový XML formát a síce šablóny fungovali s pôvodnou verziu, niektoré premenné generovali len tak rôzne XML fragmenty do HTML kódu.

Samotnú šablónu som uverejnil na Google Code hostingu ako hs3msdn2010tem­plate projekt pod BSD licenciou. Ako verziovací systém som zvolil Mercurial, pretože si myslím že umožní prípadným používateľom tejto šablóny oveľa jednoduchšie lokálne verziovanie kódu. Stačí si stiahnuť binárky a zadať tento príkaz na „naklonovanie“ zdrojákov:

hg clone https://hs3msdn2010template.googlecode.com/hg/ hs3msdn2010template

Síce HelpStudio Lite a 3 má veľkú výhodu vo vizuálnej editácie dokumentácie, slušné HTML editory, kontrolu pravopisu, rôzne podporné nástroje a jednoduché rozhranie, má aj veľa nevýhod a problémov: nezdokumentované šablóny, kompilácia je nechutne pomalá, občas padne a predávajú ho za nekresťanských cca 350? za 1 licenciu. Preto teraz študujem možnosti projektov Sandcastle a DocProject. Ale o nich nabudúce.

DreamSpark is simple; it's all about giving students Microsoft professional-level developer and designer tools at no charge so you can chase your dreams and create the next big breakthrough in technology – or just get a head start on your career.

Set global command failed on WSH Systém nemôže nájsť zadaný súbor.

Po inštalácii Service Pack 2 na Vistu pribudlo v kontexte netsh interface tcp nové nastavenie heuristics ktoré pri hodnote wsh=default robí problém a neumožňuje nastaviť autotuninglevel=nor­mal (všetky ostatné hodnoty je možné nastaviť.

Zadal som teda

netsh > int tcp
netsh interface tcp > set heuristics enabled
Ok.
netsh interface tcp > set global autotuninglevel=normal
Ok.

A už to beží. Zatiaľ neviem čo je tá nová heuristika, ale pingy to veľmi neovplyvňuje. Za to Wowko furt a furt nič. Zrejme si odpočiniem od raidy.

Potreboval som nainštalovať Windows SDK, tak som pripojil .iso image a chvíľu počkal. Autorun sa nespustil, takže som šiel do Štart > Počítač, pravý klik na cd-romku, chvíľu sa nič nedialo a nasledoval Dr. Watson, ktorý mi oznámil, že program Prieskumník sa musí reštartovať.

Na to že som ešte nestihoval nainštalovať rôzne bety a iné pofidérne programy a mám tu len tie o ktorých viem, že sú veľmi stabilné, začal Prieskumník vo Viste padať celkom rýchlo. Prvé podozrenie padlo na chybný Tortoise SVN, ktorý je zaregistrovaný do exploreru a Virtual CD ktorý do neho tiež pridáva vlastné kontextové menu. Stačí sa len dopátrať ku skutočnej príčine.

Mark Russinovich má vynikajúce články na svojom blogu o možnostiach hľadania chýb v padajúcich programoch a článok The Case of the Random IE and WMP Crashes mi naozaj pomohol a konečne som mal možnosť si skúsiť tento typ troubleshootingu.

Vo WinDbg sa stačí pripojiť na existujúci proces: File > Attach to a Process… > explorer.exe a debugovanie môže začať. WinDbg sleduje, čo sa deje v Prieskumníkovi a keď som klikol pravým na cd-romku, hneď sa zastavil na výnimke:

V Call Stacku bolo vidieť, že Virtual CD DLLka uvoľňovala pämať a zrejme tam mali chybičku.

Odskúšal som si aj utilitu adplus.vbs, ktorá je súčasťou Windows Debugging Tools. Tento skript pripojí debugger na existujúci proces (alebo spustí nový proces) a zaznamenáva 1st a 2nd chance výnimky, ktoré nastanú v programe, zaloguje ju a vytvorí memory dump z ktorého sa dajú vyčítať veľmi cenné informácie.
1st chance výnimka je taká, ktorá je v programe odchytená a viacej-menej si s ňou dokáže poradiť.
2nd chance výnimky sú všetký neodchytené výnimky a teda spôsobujú ukončenie procesu.

cscript adplus.vbs -crash -pn explorer.exe -o C:\dump

Adplus.vbs zaznamenal do logu 1st chance AccessViolation exception v <Unloaded_vc9ex­tse64.dll>+0×5f84 a okamžite aj 2nd chance AccessViolation exception čo znamená, že tam je bug.

--- 2nd chance AccessViolation exception ----
---------------------------------------------------------------

Call Site
<Unloaded_vc9extse64.dll>+0x5f84
0x1`00000000
0x7f24f90
0x4ded7a8
0x360033`00380033
0x7fe`00000037
<Unloaded_vc9extse64.dll>+0xf1c8

Čo s takouto chybnou knižnicou? Virtual CD som používal v staršej verzii, najnovšia 9.3.0 je opravená. Nie vždy však môže byť opravená verzia dostupná. V takom prípade treba knižnicu zakázať napríklad pomocou ShellExView. Veľmi často podobné padanie spôsobujú staré DivX a xvid kodeky, keď vytvárajú náhľady.