Weblog

Prípad nefunkčných aktualizácií na Windows Vista SP2

Dnes som spravoval jeden notebook s Windows Vista SP2, kde boli vypnuté aktualizácie, pretože sa ich nedarilo nainštalovať a proces inštalácie končil BSOD. Správca počítača tento problém vyriešil veľmi jednoducho: vypol aktualizácie (niekedy v januári 2011). Takmer rok neaktualizovaný notebook však nie je bohviečo a bol som požiadaný o vyriešenie problému. Windows si síce pekne sťahoval aktualizácie a aj ich pripravil na inštaláciu, ale pred reštartom, v časti „Konfigurácia aktualizácií…“ okamžite došlo k BSOD a po reštarte boli aktualizácie vrátené späť, pretože neboli v konzistentnom sta­ve.

Mini dumpy kernel aj full memory dumpy som síce mal k dispozícii, ale nemal som ich ako zanalyzovať. Pri jednom BSOD som si však všimol, že spadol ovládač eamonm.sys ktorý je z ESET NOD32 antivírusu. Na počítači bol nainštalovaní Eset Smart Security Business Edition 4.2, čo je aktuálna verzia a bol aj riadne aktualizovaný, takže bolo veľmi podozrivé, že práve tento ovládač spôsoboval pád systému. Pri obyčajnom reštarte bolo všetko v poriadku. Problém nastával iba vtedy, keď boli práve pripravené nejaké aktualizácie na inštaláciu.

Kolega z Esetu mi spravil službičku a pozrel sa na mini dumpy, avšak nikde v nich nebola zmienka o prítomnosti nejakého Eset modulu v spadnutom procese. BSOD však hovorilo jasne o eamonm.sys a tak sme skúsili pozrieť, či je všetko s NODom v poriadku. Okno O programe zobrazovali niektoré moduly s veľmi starými dátumami a bolo možné, že sa niektoré nesprávne aktualizovali. Po vyčistení cache aktualizácií (Nastavenie (F5) > Aktualizácia > Vyčistiť aktualizačnú cache), následnom vymazaní em_*.dat súborov z inštalačného priečinku NODu počas behu Windows v Safe Mode a spustení aktualizácie NODu sa znovu stiahli moduly, ktoré vyzerali byť až príliš staré.

Skúsil som teda radšej stiahnuť úplne novú verziu inštalácie NODu a preinštalovať celý produkt. Z verzie ESS 4.2.58.5 som produkt upgradoval na ESS 4.2.71.2. Aktu­alizáciou sa stiahli nové moduly a i keď verzia Self-Defense modulu zostala na verzii z konca roku 2010, vyzeralo to, že všetko je v poriadku. Neostávalo v tej chvíli len skúsiť, či sa problém s ovládačom odstránil. Nechal som Windows Update stiahnuť a nainštalovať všetko čo chcel a pri reštarte sa aktualizácie úspešne nakonfigurovali. Medzitým sa mi aj podarilo nájsť jeden príspevok o tom, že vo Windows Vista SP2 môže byť problém s niektorou verziou NODu a po upgrade na najnovší 4.2.71 sa problém odstráni. Kolega mi takisto potvrdil, že táto chyba v eamonm.sys už bola odstránená. Notebook momentálne pekne funguje, je vyaktualizovaný a podľa dostupných informácií bola príčina chyby skutočne odstránená.

PS: Neviem nakoľko je popísaný spôsob zmazania cache aktualizácií korektný a podporovaný. Vykonávajte ho iba na vlastné riziko a dajde si pozor, aké dátové súbory mažete.

VMware Workstation inštalácia skončí s chybou Error 1327

Pri upgrade na VMware Workstation 8.0.1 mi inštalácia skončila chybou „Error 1327. Invalid Drive: T:\“. Podľa VMware článkov je dôvodom nedostupná sieťová jednotka. Sieťové jednotky som nemal nastavené žiadne, ale pri kontrole som si všimol, že už nemám disk T:. Spomenul som si, že dve partície som zlúčil do jednej a na disku T: boli pôvodne uložené moje virtuálne stroje. Zrejme som zabudol aktualizovať nastavenie kam bude Workstation ukladať virtuálne mašiny. Skontrolovanie registrového kľúča HKEY_LOCAL_MAC­HINE\SOFTWARE\Wow6432No­de\VMware, Inc.\Installer\VMwa­re Workstation\DA­TASTORE_PATH potvrdilo, že tu je nastavená cesta na neexistujúci disk. Po opravení cesty na nejaký existujúci priečinok zbehla inštalácia normálne.

Visual Studio 2010 nedokáže otvoriť CSS súbory

Pri práci s webovým projektom na novom čistom počítači s Visual Studio 2010 Professional Service Pack 1 s nainštalovanými štandardnými doplnkami (Nuget Package Manager, Productivity Power Tools a PowerCommands for Visual Studio 2010) mi prestalo fungovať editovanie CSS súborov. Visual Studio odmietlo otvárať akékoľvek CSS súbory či už priamo z projektu alebo samostatne otvárané. Väčšinou bola zobrazená iba chybá hláška The operation could not be completed. Zapnutie logovania chýb vôbec nepomohlo (ako obvykle).

Podľa príspevkov na MSDN fóre Cannot open CSS file in VS2010, VS2010 not opening CSS files; drag & add not working, či na StackOverflow css file not opening in visual studio 2010 sp1? stojí za problémom zle nainštalovaný balík Web Standards Update for Microsoft Visual Studio 2010 SP1. Jeho reinštalácia naozaj pomohla odstrániť problém.

Visual Studio CSS Editor: Operation could not be completed.
Visual Studio CSS Editor: Error 2

Visual Studio 2010 – The project file cannot be loaded

Pri práci so solution pre Windows Phone 7 som na novom počítači dostal chybu „The project file cannot be loaded.“ a jeden projekt zostal neotvorený. V takomto prípade treba kliknúť pravým na projekt, vybrať Edit Project.csproj a nájsť nastavenie ProjectTypeGuids. Tu je zoznam všetkých identifikátorov typu projektu. Väčšinou sa skladá z dvoch identifikátorov: typu projektu, ako je knižnica, Windows, ASP.NET Web, ASP.NET MVC či Silverlight aplikácia a druhým identifikátorom je typ jazyka použité k naprogramovaniu, takže najčastejšie Visual C# alebo Visual Basic.

V tomto prípade bol prvý identifikátor {786C830F-07A1–408B-BD7F-6EE04809D6DB} a rýchle googlenie zistí, že sa jedná o Portable Class Library projekt.

Je škoda, že Visual Studio nepoužíva nejaké človekom čitateľné identifikátory pre typy projektov, prípadne že samotné Visual Studio nedokáže z GUIDu načítať pomocou web služby o aký typ projektu sa jedná.

Subversion 1.7

Apache Software Foundation vydal novú hlavnú verziu serveru Subversion 1.7, ktorý sa používa na správu verzií zdrojového kódu. Oficiálny build pre Windows od CollabNet ešte nie je dostupný. Bol však vydaný TortoiseSVN 1.7. Keď si budete inštalovať nový TortoiseSVN na 64bit systémy, tak použite 64bit balíček. 32bitový sa už nedá nainštalovať na tieto systémy.

Veľkou zmenou voči Subversion 1.6 je nový formát working copy (WC-NG) priečinkov – čiže súborov, ktoré máte na svojom počítači stiahnuté zo serveru. Po prechode na nový WC-NG pomocou príkazu svn upgrade už bude špeciálny .svn priečinok uložený v koreňovom priečinku celej working copy. V novom .svn priečinku bude SQLite databáza s metadátami o súboroch pre rýchlejšiu prácu celého Subversion na klientovi.

Na serverovej časti pribudol nový HTTPv2 SVN protokol, ktorý zefektívňuje komunikáciu medzi serverom a klientom. Bude použitý ak server aj klient sú vo verzii 1.7 alebo novšej. Staršie kombinácie serverov či klientov budú používať pôvodný DeltaV WebDAV protokol.

Problém s WMI query v čistej inštalácii Windows 7 SP1

Inštaloval som Windows Server 2008 R2 SP1 na nový server a hneď po inštalácii som kontroloval, či je server v dobrom stave a či Event Log neobsahuje nejaké zaznamenané chyby. V logu Application sa nachádzalo niekoľko chýb z WMI s Event ID 10. V popise bola nejaká WMI query, ktorú sa nepodarilo vykonať. Podobná hláška mi bola známa aj z Windows Vista, či Windows 7 ale tam som tomu nevenoval veľkú pozornosť.

Event filter with query "SELECT * FROM __InstanceModificationEvent WITHIN 60 WHERE TargetInstance ISA "Win32_Processor" AND TargetInstance.LoadPercentage > 99" could not be reactivated in namespace "//./root/CIMV2" because of error 0x80041003. Events cannot be delivered through this filter until the problem is corrected.

Rýchle googlenie ma priviedlo k článku KB 2545227 ktorý popisuje túto chybu. Pri tvorbe obrazu inštalačných DVD pre Windows 7 SP1 a Windows Server 2008 R2 SP1 sa táto WMI query dostala omylom do systému a je možné ju zmazať. Podobný problém sa nachádza aj vo Windows Vista SP1 a Windows Server 2008 SP1 a je popísaný v článku KB 950375. Problém môžete odstrániť pomocou skriptu priloženého v spomínaných článkoch, alebo vo Windows 7 respektívne Windows Server 2008 R2 môžete spustiť FixIt opravu, ktorá automaticky opraví systém.

Táto chyba s WMI query nie je nijako škodlivá a iba zbytočne zapĺňa Event Log chybovými hláškami. Bohužiaľ ju však treba odstraňovať na každom novom nainštalovanom Windows systéme, pokiaľ chcete mať pekný Event Log. 🙂

Znovupoužiteľné .NET knižnice pomocou Portable Library Tools

Portable Library Tools sú nástroje pre Visual Studio, ktoré umožňujú vytvoriť jednu .NET knižnicu ktorá bude podporovať viacero platforiem: .NET 4 Framework, Silverlight 4, Windows Phone 7 a XNA hry. Doteraz bolo potrebné mať jeden spoločný projekt so zdrojovými súbormi a pre každú cieľovú platformu vytvoriť zvlášť projekt a do neho pomocou linkovania pridať zdrojáky zo zdieľaného projektu. Takto bolo možné vyriešiť portovanie zdieľaného kódu existujúcej Silverlight 4 aplikácie do Phone 7 aplikácie. Lenže toto riešenie má veľké problémy so spravovaním súborov – všetky súbory trebalo ručne synchronizovať, jeden súbor sa dá vo Visual Studio otvoriť iba jeden krát, ďalší pokus o otvorenie skončí chybovou hláškou, ktorú treba odklikávať a tak podobne. Hľadanie správnych API, ktoré fungujú na všetkých potrebných platformách, tiež nebolo jednoduché. Veľmi ľahko sa programátor mohol odviazať a použiť niečo, čo zrazu v inom projekte spôsobilo kompilačnú chybu, alebo závislosť na inej DLLke (niektoré triedy z .NET 4 sú v Silverlighte 4 v inej fyzickej DLL a tak istom na Phone 7 sa nachádzajú v inej DLL). Portable Library Tools tak prinášajú obrovské zjednodušenie písania knižnice, ktorú plánujeme použiť v aplikáciách pre rôzne platformy.

Pri vývoji Windows Phone 7 aplikácie, ktorá bude používať FogBugz API, som najprv mal vytvorený Phone 7 projekt, do ktorého som prepisoval moju existujúcu implementáciu klienta pre FogBugz API. Tento klient bol obrovský, napísaný cez WCF a so synchrónnymi volaniami. Pre Phone 7 bolo potrebné kompletne prepísať veľkú čast kódu, pretože tak ako Silverlight, aj Phone 7 API obsahuje iba asynchrónne volania pri prácii s I/O a sieťou. Mohol som sa zároveň zbaviť závislosti na WCF a kód poriadne zoštíhliť. Keď som mal Phone 7 knižnicu hotovú, tak vyšla finálna verzia Portable Library Tools nástrojov a rozhodol som sa, že projekt zmením tak, aby som ho v budúcnosti mohol použiť kdekoľvek. To so sebou prinieslo niekoľko zmien v kóde, ktoré nie sú na prvý pohľad jasné a vyžadovali si trochu googlenia.

Boolean.ToString()

Jedna pomocná metóda používala volanie Boolean.ToString(CultureInfo.InvariantCulture);, ktoré nie je v PLT podporované. InvariantCulture som použil z „best-practices“ dôvodov. Boolean hodnotu som formátoval do query stringu a POST dát, takže som použil InvariantCulture, ktorá zabezpečí, že primitívny dátový typ bude naformátovaný do takéto textového formátu, ktorý bude bez problémov spracovateľný inou aplikáciou. PTL však podporuje iba Boolean.ToString() metódu. Podľa dokumentácie pre Boolean preťaženie metódy, ktoré som ja volal, úplne ignoruje parameter IFormatProvider a teda je jednoduché opraviť volanie na jednoduché ToString() bez zmeny chovania kódu.

PS: Pôvodná idea za použitím CultureInfo.In­variantCulture bola, aby som vždy dostal iba „true“ alebo „false“ stringy. Lokalizované .NETy dokážu vracať texty ako „Pravda“ a „Nepravda“. A samozrejme FogBugz server nedokáže spracovať takýto lokalizovaný text. Nemám však momentálne dôkaz, že Boolean.ToString() naozaj vráti lokalizovaný text v niektorých špeciálnych prípadoch a MSDN dokumentácia v iných jazykoch hovorí o „true“ a „false“ stringoch. Predpokladám teda, že o tento potencionálny bug sa vôbec nemusím starať, lebo neexistuje 🙂

Uri.EscapeUriS­tring(string) a Uri.EscapeDataS­tring(string)

Ako webový vývojár som zvyknutý používať triedu HttpUtility na zakódovanie textu do správne formátu, ak má byť text súčasťou URL adresy, HTML obsahu alebo atribútu. Táto trieda je však z knižnice System.Web.dll ktorá je dosť veľká a nie je vhodná ani pre desktopové aplikácie, a už vôbec nie pre Silverlight či Windows Phone. HttpUtility trieda je v týchto dvoch platformách ale prítomná v System.Window­s.Browser.dll knižnici. V Portable Library Tools ju však nenájdeme a potrebujeme náhradu. Existujú však nové metódy v triede Uri, ktoré boli pridané v .NET 3.5 SP1, ktoré rátajú s tým, že vývojári často pracujú s HTTP protokolom aj mimo webových aplikácií. Máme teda k dispozícii dve nové metódy: Uri.EscapeUriString(string) a Uri.EscapeDataString(string) ktoré sú súčasťou základnej systémovej knižnice a umožnia nám správne kódovať URL/URI adresy, query stringy a POST dáta.

Uri.EscapeUriString(string) metóda slúži pre prácu so stringami, ktoré budú súčasťou URL/URI adresy – napr. cesta k súboru na serveri a query string dáta.

-    fullServiceUrl.Query = "cmd=" + HttpUtility.UrlEncode(command);
+    fullServiceUrl.Query = "cmd=" + Uri.EscapeUriString(command);

Uri.EscapeDataString(string) metóda zase zakóduje správne stringy, ktoré budú súčasťou POST údajov.

StreamWriter writer = new StreamWriter(webRequest.EndGetRequestStream(asyncResult);
-    string name = HttpUtility.UrlEncode(param.Key);
-    string value = HttpUtility.UrlEncode(param.Value);
+    string name = Uri.EscapeDataString(param.Key);
+    string value = Uri.EscapeDataString(param.Value);
writer.Write(name + "="+ value + "&");

Synchronizati­onContext

Všetky API pre prácu s I/O sú v Silverlighte a na Windows Phone výhradne asynchrónne. Treba si preto uvedomiť, že kód aplikácia si vyžiada údaje zo serveru a tieto údaje dojdú späť asynchrónne – v inom threade. Ak teda používateľ klikne na tlačidlo „Načítaj údaje so serveru“ a handler metóda zavolá WebClient.Dow­nloadStringAsyn­c(), tak metóda okmažite skončí a grafické rozhranie aplikácie nezamrzne, lebo nečaká, kým sa stiahnu údaje zo serveru. Namiesto toho treba počkať, kým sa nezavolá ďalší handler, ktorý už dostane stiahnuté údaje. Toto sa však deje v samostatnom vlastné, ktorý je iný od UI vlákna. Načítané údaje teda môžu byť spracované a grafické rozhranie aplikácie stále nemusí byť blokované. Až po spracovaní môžeme aktualizovať UI – napr. zobraziť stiahnutý text. Toto však nemôžeme urobiť kedykoľvek. UI sa vykresluje vo svojom vlastnom vlákne a preto musíme vyslať požiadavku o zmenu UI pomocou triedy Dispatcher. Dispatcher je špeciálna trieda, ktorá vie, ako sa vykresľujú WPF, Silverlight a Phone 7 aplikácie a nie je dostupná v Portable Library Tools. Pretože PLT knižnica môže bežať v rôznych prostrediach, treba použiť namiesto špeciálneho Dispatcheru všeobecnú triedu, ktorá zabezpečí správnu synchronizáciu kódu, ktorý potrebujeme vykonať. Takouto triedou je SynchronizationContext s dvoma metódami: Post() a Send(). Ide o asynchrónny a synchrónny variant spustenia kódu v správnom vlákne, ktoré môže upravovať aj grafické rozhranie. PLT knižnica získa aktuálny synchronizačný kontext pomocou vlastnosti SynchronizationContext.Current a podľa toho, či je aplikácia napísaná pre Win Forms, WPF, Silverlight či Phone 7, tak sa použije správny synchronizačný kontext na vykonanie kódu.

Portable Library Tools sú zaujímavá vec, pokiaľ potrebujete vyvinúť aplikáciu pre rôzne .NET platformy a použiť v nich spoločný zdieľaný kód. Samozrejme treba mať namysli, že PLT sprístupnia v projekte iba tie API, ktoré sú dostupné na všetkých platformách, pre ktoré je knižnica vytvárané a z počiatku to môže byť dosť obmedzujúce. Mnohé veci sa však dajú napísať v .NETe veľmi univerzálne, avšak treba použiť správnu sadu API. Toto bol hlavne prípad odstránenia HttpUtility, na ktorú som ako webový vývojár veľmi zvyknutý. .NET sa vyvíja a niekedy je ťažké udržať krok so všetkými novými a lepšími API. Na druhej strane táto evolúcia .NETu so sebou prináša aj duplicitu API a treba sa vedieť správne zorientovať, ktoré triedy a metódy použiť v danom projekte.

Phishing z neoficiálneho obchodného registra Firmdata

Pár dní po založení živnosti mi došiel list označený ako Register obchodu a živnosti z Kopčianskej 15. Vyzeralo to skoro ako niečo úradné, so známkou pána prezidenta, na čo som si povedal, že štátne inštitúcie asi nepoužívajú paušálne platby za listy, ale pekne lepia známky. Po otvorení na mňa vyskočil 59? šek od firmy FIRMDATA. Hneď som si zanadával, že čo to má byť za skryté poplatky, veď pri zakladaní živnosti som zaplatil kolky za všetko potrebné.

Google mi však veľmi rýchlo objasnil, že sa jedná o podvodný poplatok za zápis do Registra obchodu a živnosti. Firma FIRMDATA Slovenská Republika s.r.o., a jej podobné podvodné firmy ako Informatik s.r.o., či INFODAT, prevádzkujú duplicitné, neoficiálne, nepoužiteľné a zbytočné kópie obchodných registrov a žiadajú za zápis do týchto ich kópií správne poplatky. V prípade e-mailov by sa hovorilo o phishingu, či scame, kedy firma uvádza prijímateľa do omylu.

O neserióznosti firmy FIRMDATA a jej registra hovorí samotný list, ktorý nijako nepredstavuje firmu, jej portfólio a v čom je register také „terno“, že by sa novozačínajúci podnikateľ do neho mal zaregistrovať. To že ponúkajú nejaký CD-ROM za poplatok 100? a označujú to ako databázu, podľa ktorej firmy môžu sledovať svoju konkurenciu, nebudem rozoberať, lebo je to zbytočné. Jedná sa o prázdne žvásty, ktoré majú nalákať ľudí, aby nadobudli pocit, že ich produkt má nejakú hodnotu.

Ich zavádzajúci list obsahuje len suché informácie o ponuke zápisu informácií o živnosti do Registra obchodu a živnosti, ktorý príjemca potvrdí zaplatením poplatku. Ľudia takto nadobudnú pocit, že sa jedná o poplatok, ktorý musia zaplatiť. Vzhľadom na to, že rakúsky majitelia firmy FIRMDATA majú firmy aj v iných štátoch – Rakúsku, Českej republike, Chorvátsku a Bosne a Hercegovine, predpokladám, že text listu je z právneho hľadiska korektný. Z morálneho hľadiska je to však iba trápne obohacovanie sa na základe nevedomosti a neskúsenosti iných.

Takýto list pripomína „60-eurové faktúry, ktoré SOI označila ako nekalú obchodnú praktiku“. Znovu však pripomeniem, že tieto prípady sú zrejme právne strašne odlišné, ale z hľadiska dobrých mrav úplne totožné. A záver? Treba si dávať pozor na poplatky od podivných spoločností, či už prídu klasickou poštou, alebo do e-mailovej schránky. A list buď zahodiť, alebo sa pokúsiť podať podnet na SOI.

Automatizované buildovanie softvéru

V bývalej práci som sa naučil, že je výborné mať na softvérovom projekte bug tracker (používali sme, a ešte stále používam(e) FogBugz), verziovanie zdrojového kódu (Subversion alebo Mercurial Hg) a automatické buildy (CuiseControl­.NET). Mám skúsenosť s tým, že firmy používajú repozitár so zdrojovým kódom a bug tracker systém, ale málokedy majú nainštalovaný a funkčný systém, ktorý zautomatizuje kompiláciu a nasadenie aplikácie. Súvisí to aj s tým, že buildovacie systémy sa komplikovane nastavujú a treba sa o ne starať viacej, ako Subversion repozitár či bug tracker.

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).

Fólia na iPhone 4

Kúpil som si pre svoju novú hračku (iPhone 4) ochrannú fóliu na displej, aby som na ňom nemal zbytočné škrabance. Na iPod touch sa mi osvedčila fólia LE cristal od be.ez. Po niekoľkých rokoch je displej v poriadku, na fólii sú len dve mierne ryhy ktoré je trochu vidieť pod uhlom. Väčšinou sú v balení dodávané 3ks fólií, nie je problém s ich výmenou po pár rokoch.

Pre iPhon4 som si objednal Belkin fóliu pre iPhone 4 z Alzy. Aby som nemal problémy na slnku, tak som zobral matnú „matte“ verziu. Za 8 EUR dostanete tri fólie, handričku a kartu na vyhladenie fólie a odstránenie vzduchových bublín. Nasadenie fólie je jednoduché, treba si len dať pozor na správne zarovanie. Belkin fólia je presne kopíruje rozmery obrazovky, takže aj malá odchýlka spôsobí že fólia bude pretŕčať cez okraj a nebude sedieť. Pri správnej orientácii však sedí perfektne. Samozrejmosťou sú miesta pre Home tlačidlo, kameru a slúchadlo.

V čom má však fólia sklamala je práve jej matné prevedenie, ktoré spôsobuje že svetlo z displeja je rozkladané a obraz je prekrytý vrstvou mikroskopických RGB bodiek, ktoré veľmi kazia dojem z Retina displeja.

Fóliu teda budem meniť za lacnejšiu normálnu verziu (cca 6 EUR) aby som mal obraz na iPhone taký, aký má byť.

iPhone 4 obraz

iPhone 4 obraz s matnou fóliou