Partíció formázása ext3-ra

Van egy kiváló ASUS WL-500 routerem, amiben azt szeretem legjobban, hogy külső USB-s diszket lehet rádugni és pikk-pakk kész a fájlszerver. Sajnos egy ideje azt tapasztaltam, hogy másolás közben a Windows Explorer gyakran elveszítette a kapcsolatot, miközben elég súlyosnak tűnő bejegyzések kerültek a router syslogjába az smbd-vel kapcsolatban, például:

write_socket_data: write failure. Error = Broken pipe
Error writing 64 bytes to client. -1. Exiting

Szerencsére a diszken VFAT fájlrendszer volt, így könnyen át lehetett tenni Windows alá, ahol a chkdsk talált pár hibát. Sok guglizás után arra jutottam, hogy a routerben lévő USB driver jobban szereti az ext2-ext3 fájlrendszereket, ami közül a journalig miatt én az ext3-at választottam. Na de hogy tudok egy diszket ext3-ra formázni? Mivel nem sok kedvem volt SSH alatt fdisk-kel, mounttal és a formázással bohóckodni, kényelmesebb megoldást találtam:

1. Letöltöttem és kiírtam CD-re a GParted Live CD-t, ami mindössze 115 MB és nagyon gyorsan megvolt.
2. Bootoltam a frissen sült CD-ről.
3. A boot menüben: GParted Live (Default Settings)
4. Policy for handling keymaps: Don’t touch keymap
5. Which language do you prefer: 33 (US English)
6. Which mode do you prefer: ö (ami a nullának felel meg, azaz Continue to start X to use GParted automatically)

Ezek után hamarosan betöltődött a GParted grafikus felülete, ami simán látta az USB-s diszket és gyerekjáték volt vele kattintgatva létrehozni az ext3-ra formázott partíciót.

Guglizás közben belefutottam néhány fájlrendszer meghajtóba, melyek segítségével Windows alól közvetlenül is elérhetjük a Linuxos partíciót. Nem próbáltam ki őket (nem szívesen telepítek drivereket), de még hasznos lehet:

• Ext2 Installable File System For Windows
• Ext2Fsd Project – Open source ext3/4 file system driver for Windows (2K/XP/Vista/Win7)

A fájlrendszer váltás a jelek szerint segített, azóta a Windows Explorer és a Samba is vígan muzsikál.

 

Technorati-címkék: Linux,file system

A Connect igenis működik

Időnként én is szoktam szapulni a Microsoft Connect szolgáltatását, hiszen nem egyszer előfordul, hogy az ember beküld egy hibajelenséget, amire visszajön a By Design, Won’t fix, Postponed vagy valami hasonló válasz. De legyünk őszinték, ki nem állított még be hasonló választ a saját bug trackerében? És akkor egyszer csak jön egy Closed as Fixed válasz, ami elsöpör minden korábbi kellemetlen élményt.

November elején írtam arról, hogy milyen szomorú, hogy az IIS ApplicationPooldentity nem lehet SQL Server Agent job owner, mert elbukik a felhasználói fiók ellenőrzésén. Akkor be is küldtem ezt a hibát a Connectre, hogy legalább nyoma maradjon. Egy héten belül jött a standard “thank you – we are investigating” válasz, majd kértek további infókat, aztán a szokásos csönd, el is felejtettem a dolgot. Aztán most kapom a szívderítő választ:

Hey György
I just wanted to update you that the issue was fixed and you should see it in next major release, you actually can test it on SQL12 RC0 pre-release.
Thanks
Alex Grach [MSFT]

Mindezt úgy, hogy mindössze heten szavaztak erre a hibára (köszönöm mindenkinek). Like!

Szóval íme, itt az élő példa, hogy a Connect != /dev/null. Ha hibát találtok, küldjétek be!

 

Technorati-címkék: SQL Server,IIS,security

JSON sorosítás

Már régóta nyilvánvaló, hogy az AJAX a múlté, hiszen AJAJ van helyette. Kezdetben azért volt ez így, mert kín és szenvedés volt az XMLHttpRequest objektumot alacsonyszinten matatni, de aztán jött a jQuery és azóta minden rózsaszín. Az XML-t azonban teljesen jogosan leváltotta a JSON és azóta az Ajax elnevezés már nem is egészen helytálló.

Persze mióta mindenki JSON-t használ a kliens-szerver közötti kommunikációra, egyre gyakrabban merül fel a kérdés, hogy hogyan állítsunk elő szerver oldalon JSON-t és hogyan dolgozzuk fel a JSON-ban bejövő adatokat? .NET-ben szerencsére (?) van erre több lehetőség is:

• Ha WebMethodot készítünk, akkor nem kell vesződnünk vele, a varázslat megtörténik magától.
• Ha kézzel szeretnénk, akkor ott a System.Web.Script.Serialization.JavaScriptSerializer osztály, vagy
• a System.Runtime.Serialization.Json.DataContractJsonSerializer.

Már az is elég szomorú, hogy egy frameworkön belül két osztály is szolgál ugyanarra, a nagyobb gond viszont az, hogy egyik sem tökéletes. Egyrészt sajnos mindkettőben vannak hibák, amik valahogy nem akarnak kijavulni több framework verzió óta, másrészt egyszerűen nem elég rugalmasak. Szóval rájuk férne egy kis pofozgatás, webfejlesztői szemmel mindenképp. Tudja ezt az ASP.NET MVC csapat is, csakhogy egyik névtér sem hozzájuk tartozik, így jár, aki out-of-band.

De kár szomorkodni, hiszen vannak kiváló megoldások a piacon, sőt a szabadpiacon! Ott van például a Json.NET osztálykönyvtár, ami már sok helyen bizonyított, ahol a beépített osztályok kevésnek bizonyultak. Ingyenes, rugalmas és még gyors is:

Le a kalappal James Newton-King előtt, hogy egy ilyen hobbiból megírt és még szabadon elérhetővé is tette. Köszönjük.

Akkor most egy pillanatra képzeljük magunkat az MVC csapat helyébe: van egy funkció, ami nagyon kell, ám a beépített verzió nem ideális és nincs lehetőségük megjavítani, ámde van egy külső komponens, ami jónak tűnik. A külső komponensek amúgy is beváltak már ennél a csapatnál, elég csak a jQuery-re, jQuery Validationre és Modernizr-re gondolni, amik megjelennek a projekt sablonokban.

Hogy mi lesz a preferált megoldás az MVC4-ben, arról kár most találgatni (és amúgy se mondhatom meg az NDA miatt). Én mindenesetre azt mondom, aki JSONozik, annak ideje megismerni a Json.NET-et…

 

Technorati-címkék: ASP.NET,MVC,JavaScript,JSON

COMException: Illegal operation attempted on a registry key

A COMException egy igazi klasszikus rémálom. Egyrészt ijesztő (“jajj, mit kezdjünk most ezzel?”), másrészt Champollion legyen a talpán, aki rájön, hogy igazából mi a baj. Persze a második gátlástalanul erősíti az elsőt.

Íme egy példa illusztrációként: adott egy webszerver, rajta egy ASP.NET-es alkalmazás, ami Active Directory-hoz kapcsolódik. A webhely tökéletesen működik, de a szerverre kerül egy másik web application is, ami után a DirectoryEntry konstruktor nem tud a címtárhoz kapcsolódni, helyette inkább elszáll ezzel a hibával:

System.Runtime.InteropServices.COMException (0x800703FA): Illegal operation attempted on a registry key that has been marked for deletion.

Pedig én aztán nem csináltam semmit, sem ezzel az alkalmazással, sem a címtárral, sem a registry-vel! Azért elég zavarba ejtő, az Event Logban persze semmi hasznos, a hibaüzenetben még kevésbé.

Hát akkor rajta, elő a Process Monitorral, az majd megmondja, hogy kinek melyik registry kulccsal van baja –  persze csak miután az ember leszűrte és átnyálazta a sok ezer sornyi logot. Azért előtte egy gyors apppool recycle, hátha… És bejött, azóta semmi baja a szervernek.

COM is not love.

 

Technorati-címkék: COM,IIS,error

ASP.NET MVC 4 újdonságok 5 percben

Hamarosan elérhető lesz az ASP.NET MVC 4 bétája, amit az ASPInsiders tagságnak köszönhetően már a múlt héten sikerült megszereznem. Nagyon sok kellemes újdonság van benne, közülük több is azonnal belopta magát a szívembe, ezért úgy döntöttem, hogy videó sorozatot készítek az újdonságokról. Pár részt már fel is vettem és amint feloldják az NDA-t, már teszem is ki őket a Youtube-ra.

Coming soon!

 

Technorati-címkék: ASP.NET,MVC,tutorial,video

Az ASP élt, él és élni fog

Update: Kicsit félreérthető volt a vége, ezért kiegészítettem.

Már több, mint tíz éve itt a .NET, de a mai napig előfordul, hogy valakit ki kell javítanom, hogy “az bizony nem ASP, hanem ASP.NET”. Mondhatnánk, hogy szinte mindegy is, hiszen ki a fene izzad még mindig klasszikus ASP-vel? Márpedig vannak ilyen elvetemültek, nem is kevesen! Nem is olyan rég ismét előkerült egy cég, ahol nem csak hogy eszük ágában sincs váltani, hanem folyamatosan fejlesztik tovább a régi ASP-s alkalmazást. Őszinte részvétem…

Aki hasonló cipőben jár, annak mindenképp érdemes megnézni az ASP.NET Web Pages technológiát, mert arra sokkal könnyebb váltani, és akkor már legalább ott a teljes .NET arzenál a háttérben, amiről később tovább lehet lépni.

Persze ilyenkor felmerül a kérdés, hogy meddig mehet ez így tovább? Hát ha a Microsoftot kérdezzük, akkor még legalább 10 évig, ugyanis a Windows 8 éppúgy támogatni fogja a klasszikus ASP-t, mint a korábbi verziók. Ott a Developer Preview, ki lehet próbálni. Sőt, azt is megsúgom, hogy egyelőre tervbe se vették, hogy mikor akarnak megszabadulni tőle. Bármennyire is értelmetlennek és szomorúnak tűnik, hogy még mindig vannak fejlődő klasszikus ASP-s alkalmazások, ez kiválóan mutatja, hogy ha a Microsoftnál egyszer valami bekerül a support körforgásba, akkor az jó sokáig ott is marad és lehet rá számítani.

Aggódik még valaki a Silverlightos alkalmazások jövőjéért?

Technorati-címkék: ASP.NET,ASP,Windows 8

MSG 8624: The query processor could not produce a query plan

Érdekes hibába futottunk bele már nem először: adott egy INSERT szkript, ami nagyon nem akar lefutni, az alábbi hibával örvendezteti meg a gazdáját:

Msg 8624, Level 16, State 1, Line 13
Internal Query Processor Error: The query processor could not produce a query plan. For more information, contact Customer Support Services.

Na ez az, amire az ember azt mondja, hogy könyörgöm, ez csak egy sima insert, mi ebben olyan nehéz? Úgy tűnik, hogy a probléma az idegen kulcsok és a persisted oszlopok környékén lehet, legalábbis erre utal az alábbi két Connect bug:

• Internal Query Processor Error: The query processor could not produce a query plan.
• Cannot insert into a table that with a foreign key to a table with a persisted computed column

A hiba évek óta ismert, de azért még mindig sikerül reprodukálni, tessék csak szavazni rá, hátha egyszer megjavítják.

Szerencsére van workaround (én nem hívnám megoldásnak, de működik):

SET ANSI_NULLS ON
SET ANSI_PADDING ON
SET ANSI_WARNINGS ON
SET CONCAT_NULL_YIELDS_NULL ON
SET NUMERIC_ROUNDABORT OFF
SET QUOTED_IDENTIFIER ON
SET ARITHABORT ON

Az utolsó csak akkor kell, ha az adatbázis 80-as kompatibilitási módban van.

Remélem sikerült ezzel megkímélni másokat is pár órányi debuggolástól.

Ú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