.NET címkéhez tartozó bejegyzések

C# kód futtatása Node.js környezetben Roslyn segítségével

Amikor a Microsoft Managed Languages csapata 2013. decemberében bejelentette, hogy a korábbi C# és Visual Basic fordítót lecserélték, és már a Visual Studio következő verziójának napi buildjei is egy új fordítóval készülnek, hirtelen mindenki számára egyértelművé vált, hogy valami nagyon komoly dolog van készülőben. Az új, “Roslyn” kódnevű eszköz messze túlmutat a korábbi csc.exe és vbc.exe képességein és lehetőségein, nem véletlenül kapta végül a .NET Compiler Platform elnevezést.

Itt ugyanis nem egyszerűen arról van szó, hogy szeretnénk a forráskódunkat futtatható formára alakítani, hiszen arra már sok éve volt kiváló eszközünk. A Roslyn célja, hogy a fordító tudását API-kon keresztül megnyissa a fejlesztők és a fejlesztőkörnyezetek (például a Visual Studio) előtt, azaz egy fordító-mint-szolgáltatás (compiler-as-a-service) megoldásról beszélhetünk.

Miért van erre szükség? Leginkább azért, mert a fordítók nagyon összetett szerkezetek, és futásuk közben igen komoly mennyiségű információval rendelkeznek a forráskódunkról:

compiler-architecture

Ezt a tudást vétek bezárni egyetlen eszközbe, sokkal jobban járunk, ha a fordító által felhalmozott információkból más eszközök is mazsolázhatnak. A fordító az egyetlen eszközünk, amely valóban érti a forráskódunkat, hiszen a kód minden egyes betűjéről tudja, hogy az utasítás, adat, komment stb. Ezt felhasználva sokkal jobb fejlesztőeszközöket készíthetünk, például a Visual Studio 2015 kódszerkesztőjében számos funkció a Roslyn nélkül valószínűleg soha nem valósulhatott volna meg.

Az alábbi ábra a Roslyn platform felépítését mutatja (katt a teljes képért):

roslyn-architecture

Aki szeretne minden egyes dobozt megérteni, bátran látogasson el a projekt honlapjára, én itt most csak annyit emelnék ki, hogy a forráskód olvasásától az értelmezésén keresztül egészen a futtatható kód generálásáig megtalálható itt minden, és mivel platformról van szó, természetesen mindenhez van API.

A kulcs elem a sárgával bekeretezett Syntax Tree, ami a Parser által létrehozott belső reprezentációja a teljes forráskódunknak. Az ehhez tartozó API-t hívják Roslyn Syntax API-nak, aminek segítségével nem csak forráskódból értelmezhetjük a forráskódunkat, hanem módosíthatjuk is azt. Példaként vegyük az alábbi utasítást:

Regex.Match("my text", @"\pXXX");

Ebből a Roslyn az alábbi szintakszisfát építi fel:

Turner_Figure4_hires

(A példát az MSDN Magazine Use Roslyn to Write a Live Code Analyzer for Your API című cikkéből kölcsönöztem, amiben egy Visual Studio bővítményt készítenek erre alapozva.)

Hogy mi ezt a fát pusztán csak nézegetjük, elemezzük, vagy módosítjuk is, az már kizárólag csak rajtunk múlik.

Felismerte ezt a TypeScript csapat is, és az 1.3 verziótól kezdve már a Roslyn motor szolgáltatja Visual Studioban a kódszerkesztő funkciókhoz a szükséges adatokat. Ennek köszönhetően a TypeScript fordító architektúrája nem csak hogy jelentősen letisztult, hanem egyúttal könnyebben érthetővé is vált:

typescript-architecture

Történetünk szempontjából az egyik fontos komponens az alsó dobozban szereplő Parser, a másik pedig az Emitter. A Parser feladata, hogy felépítse az absztrakt szintakszisfát – jelen esetben a TypeScript forráskódból –, az Emitter feladata pedig, hogy a szintakszisfa alapján elkészítse a fordító kimenetét – jelen esetben JavaScript (.js), definíció (.d.ts) vagy source map (.js.map) formában.

Érdemes észrevenni, hogy a Roslyn és a TypeScript architektúrája teljesen hasonló: a forráskódból előbb fát építünk, majd a fából más nyelvű kódot generálunk. A Roslyn esetén ez C# –> fa –> IL, a TypeScript esetén egy TypeScript –> fa –> JavaScript.

Mivel a két fa azonos, összekapcsolhatjuk a kettőt és így máris eljutunk az alábbi megoldáshoz:

flow

Azaz a Roslyn és a TypeScript felhasználásával képesek lehetünk C# forráskódot JavaScriptre fordítani!

A módszer előnye, hogy mivel közvetlenül a C# forráskódból indulunk ki (ellentétben például a JSIL projekttel, ahol Common Intermediate Language kódot fordítanak JavaScriptre), minden olyan információ rendelkezésünkre áll, ami a forráskódban még elérhető (például láthatóság, öröklés stb.), de egyébként a C# fordító kimenetén már nem jelenik meg. Mindez meglepően hatékony optimalizálási lehetőségeket nyújt!

Példaként vegyük a JSIL projekt oldalán elérhető Raytracer demót. A teljes C# forráskód 429 sor, a JSIL által készített JavaScript kód 793 sor. Mondhatnánk,  hogy örülhetünk, hogy egyáltalán fut, csakhogy a memória kezelése korántsem optimális:

raytracer-memory

Ugyanezt a forráskódot a Roslyn Parser + TypeScript Emitter kombináción átfuttatva az alábbi eredményt kapjuk:

raytracer-memory-2

Az Internet Explorer Developer Toolsban (F12) lévő UI Responsiveness eszköz segítségével megmértük a CPU utilization és a Visual throughput (FPS) értékeket is, és mindkét mutató jelentősen jobb értékeket mutatott.

Persze a kedvezőbb memória gazdálkodás és a jobb teljesítmény nem jön ingyen, a generált kód nagyobb lett, összesen 1844 sor. A jelentős méretnövekedést az okozza, hogy az IL kóddal ellentétben a szintakszisfa tartalmaz információt az osztályokról és azokon belül a tagok láthatóságáról, amit JavaScriptben csak körülményesen lehet leképezni, de ha megtesszük (és a TypeScript Emitter meg tudja tenni), akkor több kód letöltése árán összességében jobb teljesítményt tudunk elérni. Más alkalmazások vizsgálata során is ugyanerre a megállapításra jutottunk.

A módszer természetesen nem csak böngésző alapú alkalmazásoknál, hanem natív JavaScript alkalmazásoknál, például Node.js környezetben is működik. A fejlesztés lépései a következők:

  1. Telepítsd a Node.js Tools for Visual Studio bővítményt, ami lehetővé teszi Node.js appok készítését Visual Studioval.
  2. Töltsd le a Node.js with C# bővítményt a Visual Studio Gallery oldaláról (hamarosan elérhetővé tesszük).
  3. Telepítés után meg fog jelenni Visual Studioban a C# projektek között egy “Node.js application” nevű projekt sablon, annak segítségével kell létrehozni a projektet.
  4. Írd meg az alkalmazásod forráskódját C#-ban, ehhez természetesen használhatod a Visual Studiot.
  5. A szokásos módon működik a debuggolás (F5) és a futtatás is. A projekt sablon tartalmazza a szükséges MSBuild targeteket, ami a Roslyn és a TypeScript segítségével előállítja a JavaScript kódot, amit azután a Node.js Tools for Visual Studio fog átadni a Node.js futtatókörnyezetnek.

Tesztelőket keresünk! A Visual Studio plugin publikálása előtt szeretnénk egy szélesebb körű tesztet végezni. Ha szívesen vállalkoznál erre, kérlek itt olvasd el az útmutatót, majd hagyj egy kommentet alább és felveszem veled a kapcsolatot!

 

Frissítés:

reddit-node

http://www.reddit.com/r/node/comments/31r872/write_your_nodejs_app_in_c_with_roslyn/

 

Microsoft Nyári Akadémia – .NET vNext

Kedden a Microsoft Nyári Akadémia programsorozat megnyitásaként a .NET és az ASP.NET következő verziójáról tartottam egy bevezető előadást. Az előadásnak a “.NOT, avagy .NET vNext” címet adtam, mert az új verzió számos gyökeres változást hoz, sok esetben teljesen átírva azt, amit a .NET-ről eddig tanultunk.

Ahhoz, hogy ezeknek a változásoknak az okait megértsük, mindenképp látnunk kell azt, hogy a Microsoft másfél évtizede rakta le a .NET platform alapjait, és ennyi idő alatt ez a szakma, különösen a webes világ, rengeteget változott. Kezdetben a cég ezekre a irányváltásokra pont olyan fürgén reagált, mint egy konténerszállító teherhajó, de azután a webes termékcsapat szépen magára talált, és a teherhajóból fürge romboló lett. A WebForms ás a .NET hiányosságait szépen sorban igyekeztek pótolni, megjelent a NuGet, az MVC, a WebPages és a WebAPI.

A végeredmény azonban nem egyetlen technológia lett, hanem egymáshoz nagyon hasonló, egymással rokon programozási keretrendszerek összessége. És bár hívhatjuk “One ASP.NET”-nek, amíg az MVC és a WebAPI más filtereket használ, vagy az MVC-ben és a WebPages-ben más a HTML helperek implementációja, addig ez az elnevezés sántít.

A webes termékcsapat nagyon jól ráérzett, hogy itt egy komolyabb vérfrissítésre van szükség. És ha már újraírják az MVC-t úgy, hogy magába olvassza a WebAPI-t és a WebPagest is, akkor át lehet gondolni az ASP.NET-nek azokat a részeit is, amik valóban közösek. Elég csak a mindenhol jelenlevő HttpContext objektumra, a System.Web.dll-re, vagy a teljes végrehajtási csővezetékre gondolni. Sőt mi több, ha figyelembe vesszük az új fordító (Roslyn) és új JIT fordító (RyuJIT) képességeit, akkor fel kell hogy merüljön a BCL és a CLR cseréjének kérdése is.

A Microsoft nem kisebb dologra vállalkozott, mint hogy a .NET következő verziójára refaktorálja a BCL-t, kicseréli a runtime-ot, átdefiniálja az egységnyi kód fogalmát, elpusztítja a GAC-ot, újraírja az ASP.NET platformot, és hozzá természetesen a teljes eszközparkot. Mindezt kezdettől fogva cross-platform módon, a legmodernebb tervezési mintákat követve, a felhőre optimalizálva és a modern kor elvárásainak megfelelően nyílt forráskódú módon. És itt most nem arra a “klasszikus Microsoftos” nyílt forráskódra kell gondolni, amikor a rendszer megjelenése után sok hónappal kiteszik a CodePlexre a kipucolt forrásfájlokat, hanem arra az igazi Githubos nyílt forráskódú világra, amiben mindenki küldhet pull requesteket.

Ezekről beszélgettünk a Nyári Akadémián. Akit érdekel a diasor (és benne a demók), megtalálja a Slideshare-en:

 

A teljes platform fejlesztése egyelőre nagyon korai fázisban van, és természetesen még nagyon sok változásra lehet számítani. Aki mégis szívesen ismerkedne vele, itt kezdhet hozzá:

 

Technorati-címkék: ,,,

Megjelent a .NET Framework 4.5.2

Bejelentés és az újdonságok rövid áttekintése: Announcing the .NET Framework 4.5.2

Az újdonságokról kicsit bővebben: What’s new in the .NET Framework 4.5.2

Telepítőcsomagok:

Vigyázat, in-place upgrade! A 3.5 SP1 és korábbi verziókkal side-by-side települ, de a 4, 4.5 és 4.5.1 verziókat in-place frissíti. Ezért is lehet fontos az alábbi tudásbázis cikk:
KB 2962547 – Known issues for the .NET Framework 4.5.2

Lehet töltögetni!

 

Technorati-címkék:

.NET állásinterjú témák

Korábban írtam már C# állásinterjú kérdésekről és általános .NET architect kérdésekről is, de az az igazság, hogy egy állásinterjún ennél sokkal szélesebb témakörök jöhetnek elő. Persze lehet C#-ból is olyat kérdezni, ami talán nem mindennapos (például Shallow copy vs. deep copy), de az az igazság, hogy SQL-es vagy webes kérdések éppúgy előfordulhatnak.

Chandan Kumar Sinha, aki Indiában dolgozik szoftver fejlesztőként, ezért úgy gondolta, hogy nem egy véges listát ír az állásinterjú kérdésekről, hanem egy blogon folyamatosan teszi közzé a szerinte fontos témákat.

A .NET Interview Cracker blogon heti két-három bejegyzés születik, amelyekben eddig C#, .NET, SQL és web szolgáltatásokat érintett. A cikkek nem hosszúak, és nem is kérdéseket tartalmaznak, hanem inkább összefoglalják az adott témához tartozó legfontosabb tudnivalókat. Ez a formátum haladóbbaknak is hasznos lehet, segít feleleveníteni és rendszerezni a régen tanultakat.

 

Technorati-címkék: ,,,

Napi .NET kvíz

Mit ír ki:

using System;
using System.Collections.Generic;

public class Program
{
  static void Main()
  {
    var funcs = new List<Func<string>>();
    var urls = new List<Uri>
    {
      new Uri( "http://google.com" ), 
      new Uri( "http://bing.com" )
    };

    foreach( var u in urls )
    {
      funcs.Add( () => u.ToString() );
    }

    foreach( var f in funcs )
    {
      Console.WriteLine( f() );
    }
  }
}

Kis segítség a ReSharpertől:

resharper-warning

Ahogy a figyelmeztetés mondja, ez a kód bizony másként viselkedik C# 4.0 és C# 5.0 fordítóval! Valójában ez az egyetlen breaking change C# 5-ben.

Bár a probléma nem új (Eric Lippert már 3 éve írt róla), a fenti kódrészletet nem én találtam ki. Martin Doms blogjából kölcsönöztem, aki napi kvíz sorozatot indított .NET témában és ez az egyik feladvány (#006). A sorozat már harmadik hete tart és Martinnak sikerül igen jó kérdéseket összeszedni, amiket akár egy haladóbb .NET állásinterjú kérdéssorban is el tudnék képzelni.

A sorozat epizódjai legegyszerűbben talán a http://blog.martindoms.com/tag/quiz/ oldalon keresztül érhetők el.

Nektek melyik tetszik legjobban?

 

Technorati-címkék: ,

.NET Framework 4.5 újdonságok és régiségek

Íme a hivatalos rövid összefoglaló arról, hogy a .NET Framework 4.5 milyen újdonságokat hoz: What’s New in the .NET Framework 4.5 RC

Mindez így kapcsolódik a korábbi verziókhoz:

net-frameworks

Természetesen pár típus és tag elavul az új verzióval, na meg azért néhány breaking change is akad.

Ti minek örültök legjobban vagy mi érint kellemetlenül?

 

Technorati-címkék:

MS12-034: ugye frissítettél?

security-logoMájus 8-án, tehát internet időkben mérve évezredekkel ezelőtt, a Microsoft kiadta az MS12-034 számú security bulletint, aminek az a különlegessége, hogy szinte az összes Windows kliens, Windows Server, Office éééééééés .NET verziót is érinti, beleértve a Silverlight 5-öt is. Azaz gyakorlatilag mindenkit (érdemes megnézni az érintett termékek listáját).

A hiba nem véletlenül kapott “critical” besorolást, ugyanis távoli kódfuttatást (remote code execution) illetve jogosultsági szint növelést (elevation of privilege) teszt lehetővé. Akit érdekel, hogyan kell olyan security bugot írni, ami egy ekkora cég ennyi termékét érinti, a Security Research & Defense team blogjában kezdheti az olvasgatást.

Szóval ez tipikusan az a biztonsági rés, amit az ember nem szeretne a gépén, mégis meglepődve tapasztalom, hogy sokan még csak nem is hallottak róla. Belefutottam olyan gépbe is, ahol a felhasználó rutinszerűen nyomja el naponta többször a Windows Update újraindítást kérő figyelmeztetését, így a javítások nem tudnak teljesen települni. Ráadásul mindezt heteken keresztül, kihasználva, hogy a Windows sleep állapotból sokkal gyorsabban ébred.

A javításokról tehát jó tudni és a Microsoft valójában elég sokat tesz a gyors tájékoztatás érdekében, csak nem mindenki él a lehetőséggel. Célszerű ellátogatni a Microsoft Technical Security Notifications oldalra, ahol számos értesítési csatorna közül választhatunk. Vannak alapszintű, részletes és biztonsági szakértőknek szóló információk, amiket elérhetünk weben és RSS-en keresztül is, sőt akár e-mail értesítést is kérhetünk. Üzemeltetőknek mindenképp érdemes itt feliratkozni, de mint ahogy a konkrét példából is látszik, sokszor fejlesztőket is érinthetnek ezek az információk.

Aki inkább magyarul olvasgatna, annak a BuheraBlogot tudom ajánlani, ott tömör összefoglalók szoktak megjelenni a frissítő keddeken.

 

Technorati-címkék: ,,