Ú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

.NET 4 GDR Update (és javítás a javításhoz)

Rövidhír: megjelent egy frissítés a .NET Framework 4.0-hoz, teljes nevén Microsoft .NET Framework 4 General Distribution Release Update KB2468871 :

• Letöltés
• KB2468871 tudásbázis cikk a javításokról

A frissítés több, mint 30-féle problémát javít (cumulative update roll-up), melyek között vannak bőven adatbáziskezeléssel, hibakereséssel és webfejlesztéssel kapcsolatos hibák is, valamint 6 új “feature” is, melyek főként webfejlesztéssel kapcsolatosak.

A sok issue között nagyon elbújik egy szerintem különösen fontos fix: egy javítás javítása, ami nem csak fejlesztőket, de üzemeltetőket is nagyon érdekelhet. Történt ugyanis, hogy nem túl régen megjelent a Windows 7/Windows Server 2008 R2 Service Pack 1, de sajnos későn derült ki, hogy a telepítése után egyes ASP.NET webalkalmazások elkezdenek nem működni IIS alatt. A problémát a kiterjesztés nélküli URL-ek kezelésével foglalkozó HTTP handler és a handlerek sorrendje okozza. Ezzel kapcsolatban korábban már megjelent a KB2520479 tudásbázis cikk, de eddig csak kézi megoldás volt a bajra. Most a .NET Framework 4.0-hoz megjelent frissítés ezt a hibát is kiküszöböli, tehát most már lehet bátran a szerverre is SP1-t telepíteni.

Technorati-címkék: ASP.NET,Windows Server 2008 R2,IIS,.NET

Egy DLL minden platformra

Tavaly írtam arról, hogy Silverlightból kezd zavaróan sok változat lenni, ami már csak azért is kellemetlen, mert a DLL-ek ettől újrafelhasználhatatlanná válnak. Ezen próbál segíteni a Portable Library Tools projekt típus, aminek a kimenete szintén DLL, csakhogy erre a fájlra hivatkozhatunk .NET 4, Silverlight 4, Windows Phone 7, XNA és XBOX 360 projektekből egyaránt. A BCL csapat egyelőre csak egy CTP változatot adott ki, ami letölthető innen.

Technorati-címkék: Silverlight,.NET,Visual Studio,Windows Phone

E-mail küldés kódból – sablonnal

.NET-ből e-mailt küldeni nem nagy durranás, három évvel ez előtt már egyszer megírtam, hogy milyen egyszerűen megy ez a MailMessage és az SmtpClient osztályok segítségével. Akkor szó esett arról, hogyan kérhetünk kézbesítési nyugtát, hogyan küldhetünk egy levélen belül többféle formátumban vagy éppen aszinkron módon, és hogy hogyan trace-elhetjük a levélküldést. Egy gyakori feladat azonban kimaradt: hogyan küldhetünk úgy levelet, hogy az e-mail sablonja egy külső fájlból jöjjön, amit a kódunktól függetlenül tudunk karbantartani?

Itt jön a képbe a System.Web.UI.WebControls.MailDefinition osztály. Elsőre igen szokatlan, hogy ezt az osztályt használjuk, hiszen a többi levélküldős osztály a System.Net.Mail névtérben van, ez pedig a WebControlsban, de az a lényeg, hogy működik. A MailDefinition osztály BodyFileName tulajdonságában kell megadnunk a sablont:

  MailDefinition mail = new MailDefinition();
  mail.BodyFileName = @"~/EmailTemplate.txt";

Megadhatjuk továbbá a levél feladóját (From), hogy ki kap másolatot (CC), a levél prioritását (Priority), sőt tárgyát (Subject) is, a legfontosabb azonban az IsBodyHtml tulajdonság beállítása, amivel azt jelezzük, hogy a betöltött sablon plain text vagy HTML fájl.

Az én esetemben plain text e-mailt küldünk, ezért a sablon is sima TXT:

  Tisztelt <%DisplayName%>!
  A <%Acronym%> konferenciára sikeresen regisztrálta dolgozatát.  Köszönjük.

A sablonban természetesen helyőrzők vannak, ahova a behelyettesítendő értékek kerülnek. Fontos, hogy itt a <% %> szintaktikát használjuk, más megoldással voltak rossz tapasztalataink. Egy szótár típusú gyűjteményben (dictionary) kell megadnunk, hogy a helyőrzők helyére milyen konkrét értékek kerüljenek (nálam az emailData objektum tartalmazta a szükséges információkat):

  ListDictionary replacements = new ListDictionary();
  replacements.Add( "<%DisplayName%>", emailData.DisplayName );
  replacements.Add( "<%Acronym%>", emailData.Acronym );

A definícióból a CreateMailMessage függvénnyel állíthatjuk elő az elküldhető MailMessage objektumot, paraméterként a címzettet, a csere szótárt és egy tulajdonos Control objektumot kell átadnunk. Természetesen az így létrejött MailMessage tulajdonságait utána módosíthatjuk és már mehet is a küldés:

  using( MailMessage message =
    mail.CreateMailMessage( emailData.Email, replacements, this ) )
  {
    message.Subject = "Sikeres regisztráció";
    try
    {
        using( SmtpClient client = new SmtpClient() )
        {
            client.Send( message );
        }
    }
    catch( Exception ex )
    {
        // Naplózás
    }
  }

A levelezőszerver és a feladó adatai természetesen a web.config-ból is jöhetnek:

  <system.net>
    <mailSettings>
      <smtp from="no-reply@example.com">
        <network host="mail.example.com" password="" userName=""/>
      </smtp>
    </mailSettings>
  </system.net>

Nagyon testidegennek tűnhet egy ilyen GUI független kódtól egy olyan osztály, ami a WebControls névtérben van, ráadásul a hívott metódusának egy Control példányt is át kell adni. Ez valószínűleg onnan ered, hogy ezt az osztályt a beépített felhasználókezelő vezérlőkhöz készítették, mi csak kihasználjuk, hogy azoktól függetlenül is működik. Természetesen ugyanezt a funkcionalitást néhány perces kódolással bárki elkészítheti és akkor nincs ilyen probléma, én mégis jobban szeretem a standard, nem egyedi megoldásokat. Ráadásul ez készen van, csak használni kell.

Technorati-címkék: web,mail,ASP.NET,.NET

Mixed mode assembly hiba .NET 4 alatt

Épp WPF alól matatok SQLite adatbázist (majd a jövő csütörtöki Ethical Hacking Konferencián megmutatom, hogy miért ), ami tökéletesen működött is .NET 2.0 alatt, de mikor áttettem .NET 4 alá, az alábbi hibaüzenet köszöntött, ráadásul futási időben:

System.IO.FileLoadException was unhandled
Message=Mixed mode assembly is built against version ‘v2.0.50727′ of the runtime and cannot be loaded in the 4.0 runtime without additional configuration information.

A problémát nyilvánvalóan az okozta, hogy a netről letöltött System.Data.SQLite szerelvény még az előző framework verzióhoz készült. A mixed mode assembly egyébként olyan szerelvény, ami .NET-es és C++ kódot is tartalmaz. A hibaüzenetből kiderül, hogy valami konfigolni kell, ezért létrehoztam egy app.config fájlt az alábbi tartalommal és máris megoldódott a probléma:

    <?xml version="1.0" encoding="utf-8" ?>
    <configuration>
        <startup useLegacyV2RuntimeActivationPolicy="true">
            <supportedRuntime version="v4.0"/>
        </startup>
    </configuration>

Hasonló előjöhet webes fejlesztésnél is, ott a WebDev.WebServer40.exe.config fájlt kell kiegészíteni a startup elemmel. A useLegacyV2RuntimeActivationPolicy-ről bővebben Mark Miller blogbejegyzésében lehet olvasni.

 

Technorati-címkék: .NET,error

LinkBlog: Cheat Sheets

Gábortól kaptam az alábbi linket e-mailben, hasznos egy oldalas összefoglalók, ún. “cheat sheet”-ek találhatóak rajta John Sheehan gyűjtésében mindenféle témában: http://john-sheehan.com/blog/net-cheat-sheets/

Köszönet érte!

 

Technorati-címkék: cheat sheet

Kép átméretezése arányosan, szépen

Képek átméretezéséhez lehet használni az Image.GetThumbnailImage metódust, aminek az egyik baja, hogy nem túl szép az átméretezett eredmény, a másik, hogy vadul képes ExternalExceptionöket és OutOfMemoryExceptionöket dobálni, ha nem tetszik neki az eredeti kép. Van más lehetőség is.

Használhatjuk például a Graphics.DrawImage metódust, ráadásul a Graphics objektumnak még az InterpolationMode tulajdonságát is be tudjuk állítani:

  private static Image ResizeImage( Image originalImage, int maxWidth, int maxHeight )
  {
    if( originalImage.Width == maxWidth && originalImage.Height == maxHeight )
    {
        return originalImage;
    }

    float ratio;
    float ratioWidth;
    float ratioHeight;

    ratioWidth = (float) maxWidth / (float) originalImage.Width;
    ratioHeight = (float) maxHeight / (float) originalImage.Height;
    ratio = ratioHeight < ratioWidth ? ratioHeight : ratioWidth;

    int destWidth = (int) ( originalImage.Width * ratio );
    int destHeight = (int) ( originalImage.Height * ratio );

    Bitmap bitmap = new Bitmap( destWidth, destHeight );
    using( Graphics g = Graphics.FromImage( (Image) bitmap ) )
    {
        g.InterpolationMode = InterpolationMode.HighQualityBicubic;
        g.DrawImage( originalImage, 0, 0, destWidth, destHeight );

        return (Image) bitmap;                
    }
  }

Ha a bemenetünk stream, akkor abból az Image.FromStream metódussal lehet Image objektumot készíteni. Ha byte[], akkor még egy MemorySteam is kell és persze minden IDisposable:

    using( MemoryStream originalStream = new MemoryStream( originalContent ) )
    {
        using( Image originalImage = Image.FromStream( originalStream ) )
        {
            using( Image resizedImage = ResizeImage( originalImage, MaxWidth, MaxHeight ) )
            {
                using( MemoryStream resizedStream = new MemoryStream() )
                {
                    resizedImage.Save( resizedStream, ImageFormat.Jpeg );
                    byte[] resizedContent = resizedStream.ToArray();
                }
            }
        }
    }

Tapasztalatom szerint a 100 pixel környékére kicsinyített fényképeknél a JPEG és a PNG hasonló minőséget produkál, miközben a JPEG fájl lényegesen kisebb, nem ritkán tízszeres különbség is van.

C# programozás állásinterjú kérdések

Tegnap volt szerencsém egy hazánkban is fejlesztőket foglalkoztató multi állásinterjúkon alkalmazott C# tesztsorával egészen közelről megismerkedni. 12 papíron megválaszolandó kérdés, a szintidő 40 perc. Meg tudod oldani?

A teszt eredetileg angol, a fordítás tőlem származik.

1. Mire jó a new kulcsszó?

2. Írjon kódot, amelyben definiál egy eseményt (event), feliratkozik rá egy metódussal, elsüti az eseményt, majd leiratkozik róla!

3. Nevezzen meg négy hozzáférés módosítót (access modifier) és magyarázza meg a jelentésüket! Van-e ötödik?

4. Mi a különbség az absztrakt osztály és az interfész között elsősorban implementáció és öröklés szempontjából?

5. Írjon kódot, amelyben:

• Definiál egy IDoSomething interfészt egy f() metódussal.
• Definiál egy IDoSomethingElse interfészt egy f() és egy g() metódussal.
• Készítsen egy osztályt, amelyikben implementálja az IDoSomething és az IDoSomethingElse interfészeket úgy, hogy mindegyik metódus kiírja a konzolra a az interfész és a metódus nevét.
• Készítsen egy példányt az osztályból és hívja meg a metódusait.

6. Nevezzen meg legalább négy különbséget az érték típus és a referencia típus között!

7. Mi a reflexió (reflection), mikor használatos, mik az előnyei és a hátrányai?

8. Írja le, hogyan működik a szemétgyűjtő (garbage collector)!

9. Az alábbi egy Windows Forms vezérlő kódjának a részlete. A btnOK_Click metódus a felhasználói felületen található gombhoz rendelt eseménykezelő, az AsyncCallback pedig egy háttérben másik szálon futó művelet végén a rendszer által meghívott callback metódus. Helyes-e így az implementáció és ha nem, akkor hogyan lehet javítani?

    public class MyControl : Control
    {
        //...

        void UpdateTextBox()
        {
            this.txtName.Text = DateTime.Now.ToString();
        }

        void btnOK_Click( object sender, EventArgs e )
        {
            this.UpdateTextBox();
        }

        void AsyncCallback( IAsyncResult result )
        {
            this.UpdateTextBox();
        }
    }

10. A 9. feladatban bemutatott kód alábbiak szerint módosított változatával sikerült-e kijavítani a hibát? Lehetséges-e deadlock a kódban és ha igen, mikor?

        void btnOK_Click( object sender, EventArgs e )
        {
            lock( this )
            {
                this.UpdateTextBox();                
            }
        }

        void AsyncCallback( IAsyncResult result )
        {
            lock( this )
            {
                this.UpdateTextBox();
            }
        }

11. Mit ír ki:

    using System.Threading;

    namespace ThreadSample
    {
        class Program
        {
            public static int i;

            public static void ThreadProc()
            {
                System.Console.WriteLine( i++ );
            }

            static void Main( string[] args )
            {
                for( int i = 0; i < 4; i++ )
                {
                    Thread t = new Thread( new ThreadStart( ThreadProc ) );
                    t.Start();
                }
            }
        }
    }

12. Mit ír ki:

    using System;

    namespace CtorSample
    {
        class Base
        {
            public Base()
            {
                Console.WriteLine( "Base()" );
            }

            static Base()
            {
                Console.WriteLine( "static Base()" );
            }
        }


        class Child : Base
        {
            public Child()
            {
                Console.WriteLine( "Child()" );
            }

            static Child()
            {
                Console.WriteLine( "static Child()" );
            }
        }


        class Program
        {
            static void Main( string[] args )
            {
                Child b = new Child();
            }
        }
    }

És ez csak a teszt volt. Érdekel valakit, hogy miről beszélgettünk még utána például SQL témában?

A Mit ír ki kérdések kódjait letölthetővé tettem (ThreadSample, CtorSample), ki lehet próbálni!

 

További interjú kérdések találhatók az alábbi címeken:

• Mark Wagner: C# interview questions
• Tech Interviews: Advanced C# interview questions
• Riley T. Perry: C# Interview Questions

 

Technorati Tags: C#,interview,test

Mi kell a .NET Frameworkből?

Igazat kell adnom azoknak, akik szerint a .NET Framework óriási és képtelenség ismerni az egészet alfától omegáig. Már az is jó kérdés, hogy a Frameworkben található számos technológia közül egyáltalán melyiket érdemes megtanulni, mire lesz szükségem? Scott Hanselman kérdőíve ad néhány tippet a kérdés megválaszolásához.

Brad Adams összesítése szerint a .NET Framework 1.0 3581 típussal indult 41 szerelvényben. A 3.5 verzióra a szerelvények száma 2.5-szeresére nőtt (98), a típusok száma megháromszorozódott (11417). Patrick Smacchia szerint a még nagyobb számokról van szó. Tippelni sem merek, mi lesz a 4.0-ban. Korábban azt lehetett mondani, hogy időnként jött egy-egy technikai bumm, ami után lassan csitult el a porfelhő és eltartott egy darabig, míg a fejlesztői társadalom megemésztette. Mostanra azonban a Microsoft átment szőnyegbombázásba, nincs olyan hónap, hogy ne jelenne meg valamilyen újdonság és már képben lenni is nehéz, nem hogy elsajátítani az új technológiát. Személy szerint jobban örülnék, ha új funkciók helyett a régieket tökéletesítenék, de nincs mese, szelektálni kell. Ha csak a webfejlesztést nézzük, ki tudja megtanulni az ASP.NET MVC, Dynamic Data, ADO.NET Data Services ÉS a Silverlight használatát?

Ezért örültem MS RD kollégám, Scott Hanselman házi felmérésének, amiben 14 technológiáról kérdezte meg a résztvevőket, hogy használják-e vagy sem. Egyetlen hét alatt közel ötezer válasz jött, ebből már érdemes statisztikát készíteni, íme az eredmény:

Az nem lep meg, hogy a CardSpace a sor végén kullog, de az igen, hogy az MVC, az EF és az ADO.NET Data Services ilyen magas. Még akkor is, ha a publikáló blog olvasói valószínűleg az átlag feletti érdeklődésű és kísérletező fejlesztők és emiatt komoly fenntartással kell kezelni az eredményt. Hazai viszonylatban még a WCF sem végezne ilyen jó eredménnyel szerintem, pedig már közel két éve elérhető.

Mi a véleményetek?

NXT.NET for Lego Mindstorms

Néhány hónappal ezelőtt Dávid Zoli blogbejegyzése kapcsán figyeltem fel a Lego Mindstorms NXT készletére. Aki esetleg nem ismerné, ez egy olyan standard LEGO csomag, amiből programozható robotot építhetünk. A robot "agya" az ún. NXT Brick képes egyszerre négy szenzor jelét venni és három motort vezérelni, sőt a legszebb az egészben, hogy Bluetooth kapcsolatos keresztül távvezérelhető. Szóval nem csak egy gyerekjátékról van szó, sokkal több lehetőséget rejt ez a készlet magában. Nem véletlen, hogy a világban több helyen már ezt használják arra, hogy a diákokkal megszerettessék a programozást és elsajátíttassák a programozás alapjait. Aki nem hiszi, nézze meg ezt a videót egy Lego robotról, amelyik kirakja a Rubik kockát!

Mivel a Bluetooth kapcsolat soros portként látszik, ezért nem ördöngösség a .NET Framework SerialPort osztályán keresztül programozni. Bár ezt már többen megírták, én mégis nekiláttam, hogy életem első robotját a saját .NET alkalmazásomon keresztül távirányítsam. A dolog meglepően gyorsan működött, bár persze számos fejlesztői doksit kellett végigbújni, melyek szerencsére publikusan elérhetőek a Lego oldalán.

Az eredmény egy osztálykönyvtár lett, mely végül az NXT.NET nevet kapta. Teljes mértékben felügyelt kódban, C# 3.0-ban íródott és végül sikerült megoldani, hogy ugyanaz a forráskód változtatás nélkül csont nélkül forduljon .NET Framework 3.5-re és .NET Compact Framework 3.5-re is, tehát egyúttal a mobil változat is elkészült. A kód teljes mértékben angolul kommentezett, ide vezettem át mindent, amit a neten talált forráskódokból és dokumentációkból sikerült kiokoskodnom, így a C# fordító által generált XML kimenetből NDoc segítségével előállt az osztálykönyvtár fejlesztői CHM súgója, melyből íme egy képernyőfotó az elérhető típusok érzékeltetésére (ez is letölthető a CodePlexről):

A library teszteléséhez készült egy desktop és egy mobil alkalmazás, mindkettő természetesen felügyelt kódban. Bár még nem tud mindent, az alap kommunikáció, tulajdonságok lekérdezése, szenzorok konfigurálása és lekérdezése már megy. Ez látszik belőle Visual Studio 2008-ban:

Bár a motorok vezérlése még csak alapszinten implementált, elérkezettnek láttam az időt ahhoz, hogy megosszam az eredményt azokkal, akiket érdekel. A projekt súgóját és lefordított állományait kitettem a CodePlexre, onnan lehet letölteni őket. A forráskódokat egyelőre nem osztottam meg, de ha lesz érdeklődés a projekttel kapcsolatban, akkor tervezem azt is kitenni a netre.

Érdekel ez egyáltalán valakit rajtam kívül? Használ ma idehaza valaki Lego Mindstorms NXT-t?

 

Technorati Tags: LEGO,Mindstorms,NXT,NXT.NET,C#,Mobile,Compact Framework