Alkalmazások bemelegítése IIS 7.5 és 8.0 alatt

Mint minden szoftvernél, webalkalmazások esetén is előfordulhat, hogy az alkalmazásnak induláskor inicializálnia kell magát, adatbázis kapcsolatokat kell felépítenie, cache-t kell feltöltenie, sőt az összes olyan rendszer- és platform komponenst is inicializálnia kell, amelyre ráépül. A .NET keretrendszerre épülő alkalmazások esetén ehhez még hozzájön a just-in-time fordítás, mellyel összességében az alkalmazáshoz érkező első kérés kiszolgálása zavaróan elhúzódhat.

Erre a problémára a hagyományos megoldás az, hogy a felhasználói kéréseket megelőzve mi küldjük be az első kérést a webalkalmazásnak, így mire a valódi felhasználók megérkeznek, már a bemelegített, villámgyors honlappal fognak találkozni. Ezzel a megoldással sajnos legalább három probléma van:

• Meg kell írnunk a kliens szkriptet, ami HTTP kérésekkel bombázza a webalkalmazásunkat.
• Gondoskodnunk kell arról, hogy a bemelegítő szkriptünk az alkalmazáskészlet minden indulásakor lefusson.
• IIS 7.5 előtt a felhasználóktól érkező kérések megelőzhetik a bemelegítő szkriptet (architekturális korlát).

Szerencsére a Windows 7-ben és a Windows Server 2008 R2-ben megjelent IIS 7.5 ezen a területen jelentősen fejlődött. A kulcskérdés az, hogy az alkalmazás minek a hatására kezdi el inicializálni magát?

IIS 6 és 7.0 esetén miután megtörtént az alkalmazáskészlet inicializálása, a rendszer készen áll a kérések fogadására, ám az alkalmazás inicializálását valójában az első kérés beérkezése indítja el (katt a teljes képért):

Ennek következtében a felhasználónak meg kell várnia nem csak az általa beküldött kérés feldolgozását, hanem még a teljes webalkalmazás inicializálását is, és csak utána kapja meg a választ. A helyzetet súlyosbítja, hogy ha van már egy korábbi futó alkalmazáskészlet, akkor azt a webszerver leállítja, miután az új alkalmazáskészlet inicializálása megtörtént – csakhogy ekkor még az új worker processben a webalkalmazás nem áll készen! A felhasználónak tehát nem csak, hogy sokat kell várakoznia, de még az is feltűnik neki, hogy a korábbi gyors rendszer (az előző alkalmazáskészlet már be volt melegítve) hirtelen egy kérés erejéig jelentősen lelassult.

Az IIS 7.5-ben a fejlesztők változtattak a webszerver architektúráján, így az alkalmazáskészlet inicializálása után automatikusan megtörténhet az alkalmazás inicializálása is:

Ráadásul itt már igazi átlapolt újraindításról (overlapped recycling) beszélhetünk, mert a régi alkalmazáskészlet leállítása csak az után történik meg, hogy az újban az alkalmazás inicializálása is megtörtént, így az első kérést küldő felhasználó egyáltalán nem fogja észrevenni, hogy valójában egy új worker process dolgozza fel a kérését.

Ez a módszer azonban feltételezi azt, hogy a webszerver tudja, hogyan kell a webalkalmazást inicializálni, ami nyilván nem lehet mindig igaz, hiszen nagyon sokféle rendszer létezik. Valójában ez csak úgy tud működni, ha a webalkalmazás fel van készítve erre a funkcionalitásra, ami természetesen egyelőre nem minden alkalmazásra igaz.

Ha az alkalmazásunk még nincs felkészítve az IIS 7.5 új alkalmazáskészlet architektúrájára, akkor nem marad más választásunk, mint a korábbiakhoz hasonlóan HTTP kérésekkel bemelegíteni az alkalmazást. Itt azonban már van arra lehetőségünk, hogy ezek a bemelegítő kérések még az előtt érjék el az alkalmazást, hogy az előző alkalmazáskészlet leállna vagy a felhasználótól kérések érkeznének. Ráadásul egy új modul segítségével még a kérések beküldéséről sem nekünk kell gondoskodnunk.

Korábban az IIS 7.5-höz a Microsoft kiadott egy Application Warm-Up nevű opcionális bővítményt, ami képes volt a beállított URL-ekre a megfelelő időben beküldeni az inicializáló kéréseket. Ez a modul bár nagyon hasznos volt (főként a SharePoint üzemeltetők imádták), még a béta időszak alatt kiderült róla, hogy nem minden szempontból felel meg a Microsoft hosszútávú terveinek, ezért sajnos levették a honlapról és azóta nem volt kész megoldásunk. Az IIS 8-ban azonban beépítetten megjelent ez a funkció Application Initialization néven:

Szerencsére az IIS 7.5 számára is elérhetővé tették ezt a funkciót opcionális bővítmény formájában, aminek most a Release Candidate változata tölthető le innen:

• x64 letöltés: http://go.microsoft.com/fwlink/?LinkId=247817
• x86 letöltés: http://go.microsoft.com/fwlink/?LinkId=247816
• Fórum a kérdéseknek és válaszoknak: http://forums.iis.net/1165.aspx

A telepítés nagyon egyszerű next-next-finish, de utána ne keresgéljünk semmit az IIS Managerben, egyelőre nem tartozik ehhez a modulhoz GUI. A beállításokat vagy a config fájlokban, vagy az IIS Manager Configuration Editor moduljával tehetjük meg.

Első lépésként azt célszerű beállítanunk, hogy az application pool mindig fusson (hiszen a leállási időt akarjuk minimalizálni):

 <add name="MyPool" startMode="AlwaysRunning" ... /> 

Ennek hatására a Windows Process Activation Service (WAS) mindig el fogja indítani az alkalmazáskészletet.

A következő lépés a preloading engedélyezése az alkalmazásnál, szintén az applicationHost.config fájlban:

 <application path="/" applicationPool="MyPool" preloadEnabled="true" ... />

Ez fogja kiváltani az első kérést, ami inicializálja az alkalmazást. Már csak az van hátra, hogy meghatározzuk, mi történjen ennél a kérésnél. Ezt legszebben az alkalmazás web.configjában tehetjük meg a system.webServer szekcióban:

<applicationInitialization remapManagedRequestsTo="Loading.html" 
                           skipManagedModules="true" 
                           doAppInitAfterRestart="true"> 
  <add initializationPage="/Default.aspx" /> 
</applicationInitialization>

Az add sorokban több URL-t is felsorolhatunk, ahova  kéréseket fog küldeni a modul az alkalmazás inicializálása alatt. A remapManagedRequestsTo attribútumban pedig egy olyan oldalt adhatunk meg, amit válaszként fog visszaküldeni a rendszer az inicializálás ideje alatt (ez persze csak akkor izgalmas, ha nincs átlapolódás az előző alkalmazáskészlettel).

Ezzel készen is vagyunk. Persze lehet még tovább cifrázni, például küldhetünk vissza többféle várakozó képernyőt is, ha összekapcsoljuk az Application Initialization modult az ingyenesen letölthető URL Rewrite modullal. Ezt az teszi lehetővé, hogy az AppInit modul beállítja az APP_WARMING_UP szerver változó értékét 1-re arra az időre, amíg az inicializálás tart. Ebben a cikkben erre is szerepel példa: http://learn.iis.net/page.aspx/1089/iis-80-application-initialization/

 

Technorati-címkék: IIS,URL Rewrite,Application Initialization

Kimaradhat a XAML a Windows 8-ból

Akik esetleg követnek Facebookon vagy Twitteren már tudhatják, hogy múlt héten Dávid Zoli barátommal Szófiában voltunk.

A bolgár Microsoft múlt héten rendezte meg az MS Days 2012 konferenciát, ami egy meglehetősen komoly rendezvény fejlesztők és üzemeltetők számára. Csak hogy a méreteket érezni lehessen: két nap, 8 párhuzamos szekció, 72 előadás (melynek kb. a fele angolul), 49 előadó (akik közül sokat külföldről reptettek oda) és minderre több, mint 1000 résztvevő.

A szervezés nagyon profi volt, minden egészen flottul ment, talán csak a helyi Lurdy Ház, a Кино Арена volt egy kicsit szűkös ennyi embernek:

Zolival két előadást tartottunk JavaScriptről, HTML5-ről, MVC-ről és Azure-ról, főként tapasztalatokról és legjobb gyakorlatokról. Akit érdekel, letöltheti az előadásokhoz tartozó prezentációkat és demókat innen. Büszkén jelenthetem, hogy mindkét előadás nagyon népszerű volt, sokkal többen jöttek, mint ahányan a terembe befértek, még a “falakon is lógtak”. Az értékelőlapok összesítését még nem kaptuk meg, de a Twitteren már jött néhány pozitív visszajelzés (kettőnk közül csak én vagyok Twitteren, ezért csak engem emlegetnek, de az előadásokat együtt tartottuk):

A második előadás után megkeresett minket a Microsoft Research két munkatársa és elmondták, hogy az egyik kiemelt projektjükben kompatibilitási problémák megoldásán dolgoznak és az előadások alapján arra gondoltak, hogy szívesen bevonnának minket is. Konkrétan azon elmélkednek, hogy a XAML egy gigantikus zsákutca, mert már sok “dialektus” van belőle (Silverlight, WPF, Windows Phone, Windows 8) és mindegyik jelentősen eltér a másiktól.

Erről egyébként bárki meggyőződhet: a CODE Magazin atyja, Markus Egger egy nagyon hasznos eszközt tett közzé a CodePlexen XAML Dialect Comparer Tool néven. Az eszköz annyit tud, hogy megadunk neki egy forrás és egy cél XAML változatot, ő pedig végigszántja a névtereket és megmondja, mennyire kompatibilisek egymással. Például ha Silverlight 5-ről Windows 8 Metro-ra akarunk átállni, akkor csak 55,19%-os kompatibilitással számolhatunk. Mindenki eldöntheti, hogy a saját esetében ez mire elég.

Vissza Bulgáriához. Szóval az MSR-nél két projekten dolgoznak és mivel egy szóval sem mondták, hogy ne beszéljünk róla, elmesélem. Az egyik projekt célja, hogy XAML markupot HTML-re fordítsanak, a másiké pedig, hogy a HTML+JavaScript alkalmazásoknak 100%-osan kompatibilis környezetet biztosítsanak minden platformon. Komolyan elkezdtek azon gondolkodni, hogy a Windows 8 Metro stílusú alkalmazásoknál kínált JavaScript lehetőségek pontosan ugyanabba az irányba viszik a HTML+JS párost, mint a XAML-t: dialektikus zsákutcába. Márpedig ezt a hibát az MS nem akarja még egyszer elkövetni, így nem csoda, hogy Steven Sinofsky-t is komolyan érdeklik ezek a kutatások.

Íme egy példa! Windows 8 Metro stílusú alkalmazásban használhatunk WinJS.UI.ListView vezérlőt, így:

<div id="playeritemtemplate" data-win-control="WinJS.Binding.Template">
    <div data-win-bind="innerText:Name" style="height: 20px;" />
    <img data-win-bind="src:Photo" style="width: 200px; height: 150px;" />
</div>

<div id="PlayerListView" 
    style="height: 185px;" 
    data-win-control="WinJS.UI.ListView"     
    data-win-options="{itemRenderer:playeritemtemplate,
                       layout:{type:WinJS.UI.GridLayout,maxRows:1}}" />

Ez működik kiválóan Windows 8 esetén, de sehol máshol. Arról nem beszélve, hogy a kód elég nehezen olvasható, hiszen a WinJS.UI.ListView vezérlő hozza azt a produktivitást, ami miatt az egészet csináljuk, de fogalmunk sincs, hogy az hogyan működik. Íme egy másik példa, ezúttal egy datepicker:

<div data-win-control="WinJS.UI.DatePicker" 
     data-win-options={maxYear:2020,minYear:2000}" />

Ez is csak Windows 8-on fog bármit is produkálni, miközben dátumválasztásra mindenhol szükség van. Persze vannak tökéletes megoldások: az adatkötés megoldható például KnockoutJS-sel, a dátumválasztás pedig jQueryUI DatePickerrel. Ezek tisztán JavaScript alapú megoldások (beszéltünk is róluk az előadásunkban), tehát nincs platform probléma, feltéve persze, hogy a JavaScript futtatás nem okoz gondot az adott környezetben. Weben mindez természetes, tehát ahol webböngészőt tudunk beágyazni, ott a probléma megoldva. Nézzük sorban:

Silverlight: átfordítjuk a XAML-t HTML-re, a code behindot pedig JavaScriptre és ha a hoszt egy böngésző, akkor máris készen vagyunk. A C#-JavaScript konverzióra Nikhil Kothari Script# projektje szolgáltat megoldást. Ha out-of-browser SL alkalmazásról van szó, akkor sincs nagy gond, hiszen akkor a hoszt az explorer.exe, ami szintén beépítetten támogatja a HTML-t és a JavaScriptet (mindenki emlékszik még a böngésző beépítése körüli jogi hercehurcára). Ez egyben a SL jövője körüli kérdést is megoldja.

WPF: csakúgy mint SL-nél, itt is átfordítjuk a XAML-t HTML-re, a code behindot pedig JS-re, és mivel a hoszt itt is az explorer.exe, futni is fog vidáman. Itt már gyakrabban jöhet elő egy olyan nehézség, ami SL5-nél is, konkrétan a P/Invoke, ez ugyanis kimutat a .NET runtime adta környezetből. Erre még nincs teljeskörű megoldás, egyelőre ott tartunk, hogy aki P/Invoke-ra épít, annak valószínűleg kevésbé fontos a hordozhatóság, de ez még nem kielégítő válasz.

Windows Phone: biztos hallottátok már azt a pletykát, hogy a Windows Phone 8-nál cserélni fogják a kernelt, ami már a Windows 8-ra fog épülni. Ezt egyelőre sem megerősíteni, sem cáfolni nem tudom (ugye értitek ), a mi szempontunkból csak az a lényeg, hogy ez lesz a legkevésbé fájdalommentes. Ami a Windows Phone 7-et illeti, ott szóba se jöhet egy kernel szintű módosítás, ezért valószínűleg egy runtime réteg fog bekerülni valamelyik frissítésbe, ami gyakorlatilag egy transzparens böngésző lesz a HTML alapú alkalmazások futtatására.

Windows 8: ez a legrizikósabb terület, ugyanis pont itt reklámozta az MS legjobban az új HTML lehetőségeket és most ebből kellene visszalépni a helyes útra, ami persze egy marketing öngyilkosság lenne. Bár erre bármikor lehet azt mondani, hogy eddig csak “preview” változatok láttak napvilágot, ami magában hordozta a változtatás lehetőségeit, és hogy csak az a fontos, hogy a végeredmény hosszú távon jó legyen. A Microsoft Research-ös srácokkal arról beszélgettünk, hogy Sinofsky képes lenne szembemenni a cégen belüli marketing gépezettel a profi végeredmény érdekében.

Felmerülhet persze még kérdésként a sokféle “form factor”, azaz a cél eszközök különböző mérete. Hogyan fognak megjelenni az alkalmazásaink egy kicsi telefonon vagy egy nagyobb monitor képernyőjén? Ezzel kapcsolatban szerencsére pont a Windows 8 miatt már kitalálták a megoldást, érdemes elolvasni Nacsa Sándor idevágó Standards-based adaptive layouts in Windows 8 (and IE10) című írását.

Szintén érdekes problémakör az adattárolás kérdése. Itt az a szerencse, hogy a sok XAML környezet közül már a legkisebb is hozza a közös nevezőt: a Mango óta Windows Phone-on is lehet SQL Compact Editiont használni. Ha pedig külső SQL Serverre van szükség, akkor pedig maradnak a HTTP alapú REST-es API-k az adatbázis elérésére.

Mindezek a projektek gyönyörűen haladnak az MSR-nél, vannak működő megoldásaik nem csak egyszerű, hanem összetettebb alkalmazásokra is. Az igazi probléma az időzítés. Az MSR nem elég nagy ahhoz, hogy az igazi bevételt termelő Windows gépezetet visszatartsa, márpedig ha a Windows 8 megjelenik a Consumer Preview-ban található XAML és a HTML lehetőségekkel, akkor már nincs visszaút, az MS végérvényesen belezöttyen a kátyúba, ahonnan évekig nem mászhat ki (lásd VB6 és ASP támogatás Windows 8-on).

Ennek a meccsnek két eredménye lehet:

1. Marad a mostani felállás, amivel útjára indítják a Windows 8-at mint egy gigantikus kísérletet, és az esetleges problémákat, zsákutcákat majd a Windows 9-ben kijavítják. Ebben az esetben a történelem a Vista-Windows 7 párost ismételné.

2. Sinofsky a sarkára áll és azt mondja, hogy tiszta szerencse, hogy időben észbe kaptunk, szorítsuk egy kicsit háttérbe a saját érdekeinket és adjunk ki egy olyan Windows 8 verziót, ami tényleg hosszú távon jó irányba mutat, hiszen operációs rendszert nem cserélnek sűrűn sem a végfelhasználók, sem a cégek.

Sinofsky már letett valamit az asztalra, és én arra tippelek, hogy elfogadnák az érvelését, bár ez nagy érvágás lenne a Microsoftnak. Ebben az esetben ugyanis jelentősen csúszna a Windows 8 kiadása (az idén biztosan nem lenne belőle semmi), hozzá kellene igazítani az eddig elkészült alkalmazásokat, fejlesztőeszközöket, mindent. Viszont arra is nagyon jó esély van, hogy a végeredmény nagyon jó termék lenne, amivel az MS tiszteletet érdemelhetne ki, ami persze végül a bevételi oldalon is éreztetné a hatását. Így nem meglepő, hogy jelenleg ez a valószínűbb lehetőség.

De mi lesz a fejlesztőkkel ebben az esetben? A XAML halála a WPF és a Silverlight bizonytalan jövője körüli homályos információk óta egyre valószínűbb. A XAML diverzitása a saját halálát okozza, miközben lényegében semmi előnyt nem hordoz a HTML-hez képest, hiszen csak címke parszolásról van szó. Elég csak az ASP.NET MVC 4-ben lévő Razor parserre gondolni és máris tisztán látszik, hogy a HTML alapú megoldások egyszerűen jobbak. (Egyébként a Razor parser is bekerült ebbe a projektbe) Nincs értelme fenntartani egy olyan szintaktikát, ami megosztja a fejlesztői tábort, miközben van egy olyan alternatíva, ami inkább újabb fejlesztőket hozna a Windows platformra.

Ti örülnétek, ha a XAML halála miatt csúszna a Windows 8 kiadása?

 

 

UPDATE: Fontos kiegészítés a fentiekhez: http://bit.ly/xamltohtml

 

Technorati-címkék: Windows 8,HTML5,Twitter,XAML,event

Windows 8 kézzel-lábbal

Aki a Windows 8 megismerésébe fog, az bizony először nem talál semmit. Pedig minden megvan, csak éppen máshol, és néha különösen nehézkesnek tűnik egyes funkciók elérése egérrel vagy épp billentyűzetről.

A jó hír az, hogy a legtöbb funkció vagy menüpont elérhető valamilyen billentyűkombinációval, egérrel és touch gesztusokkal is. Az alábbi néhány cikk segíthet a rendszer felfedezésében:

Windows Experience Blog: Getting around Windows 8 – ebben a cikkben van egy PDF (vagy XPS) táblázat, ami összefoglalja a gyorsbillentyűket.

Colin Melia (MVP és RD): Navigating Windows 8 Beta with only touch, mouse or keyboard – szintén tartalmaz egy hasznos táblázatot, amiben nemcsak a billentyűk, hanem a gesztusok és az egér trükkök is szerepelnek.

Dr. Zhiming Xue (“Dr. Z”): Windows 8 Consumer Preview power user how-to series – 30 részes sorozat néhány hasznos funkcióról.

Ami nálam nagyon bevált:

• Win és Win+D: váltás a Metro Start Screen és a desktop között
• Win+Q: program keresése
• Win+X: power commands a Start menü helyén
• Win+I: az aktuális program beállításai a Charms Baron

Ti mit használtok még?

 

Technorati-címkék: Windows 8

Klasszikus asztal bejelentkezéskor Windows 8-on

JoeX készített egy kiváló ClassicStarter nevű programot, amivel Windows 8-on ki lehet erőszakolni, hogy bejelentkezés után ne a Metro Start képernyő, hanem a klasszikus desktop jelenjen meg. Általában nem szeretem az operációs rendszer nem támogatott variálásait, de ez nagyon felkeltette az érdeklődésemet, hiszen hasznos funkcióról van szó Egyrészt érdekelt, hogy működik, másrészt biztos akartam lenni benne, hogy nem csinál semmi olyat, amit nem szeretnék (mégiscsak adminként fogom futtatni a gépemen).

Szerencsére .NET-es alkalmazás, így előkaptam hozzá az ILSpy-t és megnéztem, mi van az .exe-ben. A jó hír, hogy semmi gyanús, tehát én bátran merem majd futtatni.

A kívánt eredményt pedig úgy éri el, hogy létrehoz egy ütemezett feladatot, ami az aktuális felhasználó bejelentkezésekor fog lefutni, és amely meghívja az IShellDispatch4.ToggleDesktop függvényét. Tehát semmi hack, semmi registry buherálás rég elfelejtett kapcsolókkal, hanem tiszta Shell32 API hívás. Gyönyörű!

Köszönjük JoeX!

 

Technorati-címkék: Windows 8

IIS 8.0 Express Beta

Olyan ez, mint az augusztusi csillaghullás, csak úgy záporoznak az égből a béták, minden napra jut belőlük pár. Ezúttal az IIS csapat eresztett meg egyet, mégpedig az IIS 8.0 Express bétáját, ami innen tölthető le. Érdekes, hogy néhány kivételével sikerült minden IIS funkciót megvalósítaniuk az Express változatban, ami nem csak hogy Windows 8-on, hanem Windows Vista SP1-től kezdve minden Windows verzión fut! XP tulajdonosok maradhatnak a 7.5-nél (ez jön egyébként a mostani Visual Studio 11 bétával is).

Az újdonságok és korlátozások listája megtalálható a Readme-ben.

A “nagy” IIS telepítése Windows 8-on egyébként sima ügy, bár kicsit tovább tartott, mint korábban Windows  7-en, ami valószínűleg annak volt köszönhető, hogy pár csomagot a Windows Update-ről rántott le frissen (ami viszont dicséretes). Utána viszont gondban van az ember, mert sehogy sem lehet elindítani az IIS Managert, hiszen amíg a kereső le nem indexeli, addig hiába keresgélünk rá a Search Baron. Aki nem akar 1-2 percet várni, az kapcsolja be a Charm Baron a Start Screen Settings-ei között a Show Administrative Tools kapcsolót, ami után megjelenik az IIS szokásos ikonja a Metros Start képernyőn.

Az IIS Managert elindítva a szokásos látvány fogad:

Úgy tűnik, hogy nincsenek eget rengető újdonságok, ami részben igaz is, hiszen a fő újdonságok az egyes funkciók skálázhatóságával kapcsolatosak, ami elsősorban shared hosting környezetben lesz fontos (pl. több ezer site egy gépen). A lényeg tehát a motorháztető alatt van, de azért itt-ott kicsillan egy-egy igazi gyöngyszem, például:

 

Technorati-címkék: IIS,Windows 8

Windows 8 elaltatása távolról

Remote Desktop kapcsolaton keresztül sehol nem találok Sleep opciót a távoli gép elaltatásához, és ahogy látom a shutdown is csak hibernálni tud (/h), sleepelni nem.

Szerencsére a Desktopon lehet ALT+F4-et nyomni, amire feljön az alábbi ablak:

 

Technorati-címkék: Windows 8

Hasznos Visual Studio eszközök Windows 8 Metro stílusú alkalmazások készítéséhez

Egy ideje nyúzom a Visual Studio 11-et és találtam benne több hasznos eszközt is, ami sokat segít Metro stílusú alkalmazások készítésekor. Íme a kedvenceim:

Simulator

Hozzá vagyunk szokva, hogy az emulátorok általában körülményesek és lassúak, de ha már próbáltuk a Windows Phone Emulatort, akkor rájöhettünk, hogy ez nem mindig van így, sőt kifejezetten hasznosak fejlesztéskor. A Visual Studio 11-ben kapunk egy szimulátort, ami nagyon praktikus Metro stílusú alkalmazások teszteléséhez (katt a nagyobb képért):

Jobb oldalon sorban a funkciók:

• Mouse mode
• Start touch emulation
• Touch emulation pinch/zoom
• Touch emulation rotate
• Rotate simulator clockwise
• Rotate simulator counterclockwise
• Change resolution
• Set location
• Capture screenshot
• Screenshot settings
• Help

Amint látható, belepakoltak egy rakás olyan funkciót, amit egyébként csak fizikai eszközön lehetne kipróbálni. Külön érdekes, hogy a fenti gépen látható elrendezést én nem a szimulátorban állítottam össze, hanem ez pontosan megegyezik a hoszt gépem Start képernyőjével (remote desktop). A Simulator egyáltalán nem tűnik lassúnak (bár igazán pörgős alkalmazással még nem teszteltem), ráadásul közvetlenül a Studio toolbarjáról szabályozhatjuk, hogy ott induljon a programunk:

DOM Explorer

Miután sikerült elindítanunk az alkalmazást, jöhet a hibakeresés, ami weboldalaknál és most már JavaScriptes Metro stílusú alkalmazásoknál a layout és a CSS kipofozásával kezdődik. Itt lehet óriási segítség a Debug – Windows menüből elérhető DOM Explorer ablak, ami lényegében egy Internet Explorer Developer Toolbar Metro alkalmazásokhoz:

Az IE Developer Toolbar funkcióit nem kell bemutatnom, a Select Element gombra kattintás után itt is ugyanúgy rábökhetünk akár a Simulatorban, akár a futó alkalmazásban bármelyik felhasználói felület elemre és megnézhetjük a hozzá tartozó DOM részletet. Újdonság viszont, hogy a felső részen látszik, hogy az adott DOM elemet melyik fájl generálta és egy kattintással megnyithatjuk az adott forrásfájlt. Ez azért izgalmas, mert a bal oldalon nem a forráskódunk látszik, hanem a forráskód által fabrikált kész DOM, tehát egy lista esetén például már a renderelt DOM-ot látjuk, nem az item template-et. A böngészős dev toolbarhoz hasonlóan itt is lehet bármit röptében módosítani a kódban, ami azonnal megjelenik a felhasználói felületen (ami nem meglepő, hiszen a kódunkat az IE futtatja a WWAHost processzen belül).

Szintén nagyon hasznos a jobb oldalon található Events fül, ahonnan pedig az elemhez tartozó eseménykezelőkre ugorhatunk. Íme például egy AppBar button lelkivilága:

Refresh Windows app

Persze előfordul, hogy a hiba nem a HTML vagy CSS fájlban, hanem JavaScript kódban van. Ilyenkor egy igazi webfejlesztő csak belejavít a kódba, nyom egy gyors F5-öt és máris teszteli a javítást a böngészőben. Szerencsére ennek is van megfelelője itt, úgy hívják, hogy Refresh Windows app és megtalálható a toolbaron, vagy indítható közvetlenül a CTRL+SHIFT+R kombinációval (hamar megtanulja mindenki):

Sajnos nem csak az adott oldalt frissíti, hanem újraindítja az egész alkalmazást, de úgy vettem észre, hogy még mindig ez a leggyorsabb megoldás.

 

Nektek mi jön be leginkább az új Studioban?

 

Technorati-címkék: Windows 8,Visual Studio,Metro

VB6 Never Dies

Akárcsak a klasszikus ASP-t, a Visual Basic 6-ot is teljes mértékben támogatni fogja a Windows 8, erről itt érhető el a hivatalos közlemény. Ez azt jelenti, hogy még legalább 10 évig vidáman futhatnak a jó öreg VB6 alkalmazások, és ez nem lesz gátja a Windows 8 terjedésének. Plusz pont a kompatibilitásért.

Meg tudom érteni, hogy sok régi alkalmazást nem akarnák átírni csak azért, mert változik alatta a platform, miközben a funkciók tökéletesek. Azért érdekes lett volna látni, ahogy sok VB6 fejlesztő 10 év után kilép a Mátrixból és megkérdezi, hogy mennyit aludtam, mi is az aktuális vastag kliens technológia, Windows Forms, WPF, Silverlight, WinRT, és ti ezt hogy tudjátok követni?

 

Kép innen: http://guy.dotnet-expertise.com/

Technorati-címkék: Windows 8

Új év, új .NET. Vagy mégsem?

BUÉK! Aki belegondolt már abba, hogy mi minden várható az idén a Microsofttól, annak biztos ott szerepel a lista elején az új .NET. Lesz új Visual Studio, új C# és új .NET Framework, ami a keresztségben a 4.5 verziószámot kapta. Hogy miért éppen 4.5? Mert a DevDivnél az a szokás, hogy:

• új CLR –> major verziószám változás (pl. 4.0)
• javított CLR és új könyvtárak –> minor verziószám változás (pl. 4.5)
• javítások és apróbb kiegészítések –> revision verziószám változás (pl. 4.0.2)

Márpedig az új verzióban lesznek javítások és újdonságok is, ezért lett épp 4.5. Kár, hogy semmit nem fogunk látni ebből.

Az új verzió ugyanis felülírja a régit hasonlóan, mint ahogy a 3.5 és a 3.5 SP1 felülírta a 2.0 verziót. In-place update. Ez önmagában nem is lenne igazán nagy gond, ami viszont nagyon fáj, hogy a verziószám marad a régi. Igen, pont ugyanaz:

“One of the first things you’ll notice about .NET 4.5 is the version number (4.0.30319) is the same as .NET 4; this is the practice used by other in-place updates.”

Magyarul jön az új Framework, valaki feltelepíti és utána az összes 4.0-ra írt alkalmazás kénytelen lesz azt használni. Ez van, nincs választási lehetőség, nesze, íme, újabb, szebb és jobb.

(Őszintén szólva ennek hallatán az első kifejezés, ami eszembe jutott, a DLL-hell volt, pedig mióta van korrekt Windows Installer és a .NET 2.0-nál elmondtuk, hogy milyen jó a side-by-side telepítés, ezt a fogalmat nyugodtan száműzhettem az életemből.)

Jobban belegondolva még az azonos verziószám sem lenne gond, ha nem lennének breaking change-ek és kompatibilitási problémák. Biztos vagyok benne, hogy az MS nagyon komolyan veszi ezeket az eseteket, nem is tehetik máshogy:

“Our primary concern is guaranteeing applications you use do not break after you install .NET 4.5. We accomplish this by running hundreds of application in our compatibility lab to find issues as soon as they’re introduced. While designing new features or changing existing code, we keep compatibility in mind. And a small group of us, the Developer Division Compatibility Council (DDCC), monitor changes made by developers. We review potential breaking changes, and help teams understand and assess the compatibility impact of new features and bug fixes. For .NET 4.5, members of DDCC reviewed every proposed breaking change, every new feature, and a majority of the bug fixes for the release.”

Persze azt ők is beismerik, hogy nagyon nehéz tökéletes munkát végezniük:

“We’ve put a lot of effort into maintaining a consistently high bar for compatibility across the product, yet we know some issues may get past us. Many applications will exercise the .NET Framework in ways that we did not expect or we lack test coverage for. Still we care about knowing every issue, even those that may seem like corner cases.”

Ha valamelyik alkalmazásunk megpurcan az új frameworkön, akkor lehet a Connecten jelenteni a hibát – és majd lesz valami.

A legszomorúbb az egészben az, hogy a technológia képes lenne a side-by-side működésre, nekünk mégsincs választási lehetőségünk. Valamilyen elvtől vezérelve eldöntötték Redmondban, hogy márpedig in-place upgrade lesz. Tehát ha egy szerveren egy alkalmazás miatt szükség van a 4.5 verzióra, akkor azon a szerveren a telepítés után minden 4.0 alkalmazás a 4.5 verzión fog futni. De ki fogja tudni garantálni, hogy a korábbi alkalmazások teljesen jól működnek az új frameworkkel? A legtöbb esetben senki, vagy csak jelentős munka árán. Mivel az üzemeltető nem fog ilyen kockázatot (vagy munkát) vállalni, nem fogja engedni a 4.5 verzió telepítését, mert fél, hogy a korábbi jól működő rendszerek megborulnak tőle. Üzemeltetőként én sem vállalnám, oda a bizalom. A Microsofttal szemben is és a fejlesztők felé is.

Szerintetek ez jó így?

Technorati-címkék: .NET 4.5

Így bootol a Windows 8 mindössze 2 másodperc alatt

Érdemes megnézni az alábbi hivatalos Microsoft videót arról, hogy mennyivel kellemesebb lesz a Windows 8 boot ideje a korábbi verziókhoz képest. Ne pislogj közben, mert lemaradsz:

Hát igen, tényleg sokkal gyorsabban fog elindulni a következő Windows verzió, tisztelet és gratuláció a fejlesztőknek!

De amikor arról álmodozunk, hogy az otthoni gépünket majd ilyen villámgyorsan fogjuk elindítani, gondoljunk az alábbiakra:

• A videón egy olyan szűz gép szerepel, amin még nincs telepítve kismillió extra szoftver és hardver, ami lassítja az életünket. És a te gépeden?
• A videón lévő gépben nem BIOS van, hanem UEFI. És a te gépedben?
• A videón lévő gépben nem forgó HDD van, hanem SSD. És a te gépedben?
• A csajszi kivette az aksit a gépből, ami valljuk be, nagyon meggyőzőnek tűnik, de jelen esetben inkább nagyon David Copperfieldes. Valójában ugyanis nem a klasszikus értelemben vett hidegindítás történik, hanem a hagyományos hidegindítás és a hibernálás keveréke, amin a kivett aksi nem változtat.

Nagyon profi, amit a Windows 8 csapat véghezvitt, ugyanis jelentősen megváltoztatták a boot folyamatot annak érdekében, hogy nekünk, felhasználóknak jobb legyen. Az ilyen architekturális módosítások természetesen a mostani, BIOS-os, hagyományos HDD-s gépeket is segíteni fogják, de amikor a két másodpercről álmodunk, akkor ne felejtsük el, hogy almát hasonlítunk össze körtével. Idővel persze, ahogy cserélődnek a gépek, egyre közelebb kerülünk majd az áhított pillantásnyi időhöz.

Akit érdekel, hogy ez hogyan lehetséges, annak feltétlenül ajánlom a Building Windows 8 blog idevágó bejegyzését.

 

Technorati-címkék: Windows 8