augusztus, 2007 havi archívum

Javítások a könyvekhez

Posted: 2007. augusztus 21. in Egyéb
Nem régiben Balássy Gyuri blogjában olvastam arról, hogy a 70-528-as Training Kit-es könyvhöz kitette az MS Press a javításokat. A linket betettem a Linkajánlóba, illetve ide is:
MCTS Self-Paced Training Kit (Exam 70-528): Microsoft .NET Framework 2.0 Web-Based Client Development Comments and Correctionshttp://support.microsoft.com/kb/930739
  
A 70-536-os vizsgához tartozó könyvhöz nem egy, hanem egyből kettő hibajavítás jegyzék is megjelent. Elérhetőek ez is szintén a Linkajánlóban, illetve íme a linkek:
MCTS Self-Paced Training Kit (Exam 70-536): Microsoft® .NET Framework 2.0—Application Development Foundation comments and corrections Part 1http://support.microsoft.com/kb/923018
MCTS Self-Paced Training Kit (Exam 70-536): Microsoft® .NET Framework 2.0—Application Development Foundation Comments and Corrections Part 2http://support.microsoft.com/kb/935218
 
Kellemes olvasgatást hozzájuk!
Chapter XIV. Reflection (Reflexió)
 
A reflexió nem más, mint típusokról való információ kinyerés(modulokon, assemblyken keresztül), és dinamikus típus készítés. A reflexiónál két névteret szokás megemlíteni a System.Reflection-t illetve a System.Type-ot.
 
A könyvben kivételesen eléggé részletesen le van írva minden a reflexióval kapcsolatban, ezért tényleg csak néhány kiegészítést tennék.
Ha már a könyvben annyi szó volt a biztonságról, akkor itt is érdemes egy-szót ejteni róla.
 
Alapesetben a reflexió segítségével csak és kizárólag publikus tagokhoz (public members) férhetünk hozzá. Ha szükségünk van protected vagy ne agy isten private tagokra, akkor hívjuk segítségül a Bolygó Kapitányát . Na jó, ha őt nem is, de a ReflectionPermisson osztályt már annál inkább. A jogosultságokat a ReflectionPermissonFlag enumerátor segítségével szabhatjuk meg, amelyet a ReflectionPermission objektum a konstruktorában vár. Mivel ez az enumerátor meg van jelölve a FlagsAttribute attribútummal, így egyszerre több értéket is felvehet.
A ReflectionPermissionFlag enumerátor alá a következő tagok taroznak:
AllFlags: ez egyenlő azzal, mintha a MemberAccess, ReflectionEmit és a TypeInformation lenne beállítva. 
MemberAccess: minden tagja láthatóvá válik. Ha ez nincs beállítva, akkor csak az alapból látható (public) tagok elérhetőek!
NoFlags: a „láthatatlan” tagokra nem alkalmazható a reflexió. 
ReflectionEmit: engedélyezi a System.Reflection.Emit osztály használatát.
TypeInformation: A memberaccess régi változata, így ennek használatát inkább már kerüljük.
Néhány hasznos metódusa a ReflectionPermisson osztálynak:
IsSubsetof: megvizsgálja, hogy a jelenlegi jogosultság részhalmaza-e a beállított jogosultságnak.
Union: a jelenlegi és egy általunk megadott jogosultság uniója, amely egy új jogosultságot eredményez, pl.:
ReflectionPermission reflectionPerm1 = new ReflectionPermission(ReflectionPermissionFlag.MemberAccess);
ReflectionPermission reflectionPerm2 = new ReflectionPermission(ReflectionPermissionFlag.ReflectionEmit);
ReflectionPermission reflectionPerm3 = (ReflectionPermission)reflectionPerm1.Union(reflectionPerm2);
Intersection: az unió ellentéte, vagyis a metszet. Hasonlóképpen működik, mint az Union.
FromXml, ToXml: sorosításhoz
Assert, PermitOnly, Demand, Deny, stb. – a CodeAccessSecurity-nál tanultakhoz hasonlóan működik, mivel a CodeAccessPermission-ből vannak származtatva.
 
Akit bővebben érdekel ez a téma az alábbi cikket ajánlom:
.NET Security Blog : When is ReflectionPermission Needed?http://blogs.msdn.com/shawnfa/archive/2005/03/08/389768.aspx
 
Illetve egy pár esti olvasmány a Reflection-ről:
How to: Hook Up a Delegate Using Reflection  – http://msdn2.microsoft.com/en-us/library/ms228976.aspx
Use Reflection to Validate Assembly References—Before Your Customers Dohttp://www.devx.com/dotnet/Article/28490?type=kbSampleProd&trk=MSCP
Real-world Reflection in .NEThttp://www.devx.com/dotnet/Article/31578/0/page/1
Reflection in .Net – Develop & Use Dynamically Pluggable Components (Part I)http://www.programmersheaven.com/2/Dot-Net-Reflection-Part-1
Reflection in .Net – Develop & Use Dynamically Pluggable Components (Part II)http://www.programmersheaven.com/2/Dot-Net-Reflection-Part-2
 
 
A reflexióval kapcsolatban szeretném nektek még megmutatni Lutz Roeder Reflector nevű programját. A srác alkalmazása képes .NET assembly-ket illetve saját szerelvényeket is „kibontani” reflexió segítségével. Azért mondom, hogy kibontani, mert az IL kódot visszaalakítva megnézhetjük az egyes névterek tartalmát az alábbi nyelvek bármelyikén: IL, C#, Visual Basic, Delphi, MC++, Chrome. Ezt úgy tehetjük meg, hogy valamelyik típusra vagy annak valamelyik member-jére jobb klikkel kattintva a helyi menüből kiválasztjuk a Disassemble menüpontot.
Az ugyanitt lévő Analyze menüponttal pedig megnézhetjük, hogy az éppen kiválasztott tagra kik hivatkoznak, kik használják, stb. (Depends on, Used by,  Exposed by, Instantiated by).
A progi jelenlegi 5.3-as verziója innen tölthető le:
http://www.aisto.com/roeder/dotnet/
A hozzátartozó ás a VS-hez tartozó Add-Ins-ek pedig, az alábbi link alól érhetőek el:
http://www.codeplex.com/reflectoraddins
Jó túrázást kívánok mindenkinek a .NET legfontosabb assembly-ben (mscorlib, System, stb.)! 
 
 
Végül egy nem teljesen a reflexióhoz kapcsolódó dolog, aminek inkább csak a szerelvényekhez van köze. Konkrétan az egyedi fejlesztésű vezérlők regisztrálására gondolok. Ezek is ugyebár dll-be fordulnak le, így ha az alkalmazásunkban szeretnénk őket használni, akkor létre kell hozni rá egy hivatkozást. A custom/composite controlokra való hivatkozást egy regisztráció (@Register direktíva) segítségével végezzük el a markup fájlban. Íme egy példa:
<%@ Register Assembly="AjaxControlToolkit" Namespace="AjaxControlToolkit" TagPrefix="aspextenders" %>
Nos kifejezetten ennél a példánál maradva, tehát az AJAX Control Toolkit-nél, nem valami jó megoldás az, hogy minden oldalon ahol használjuk valamelyik vezérlőt a 35 közül, bekerül a fenti regisztráló rész. Ráadásul a tagprefix nem is aspextenders lesz, hanem cc1, amelyet mindig átírhatunk. Így erre egy megoldás az, ha az assembly-t a web.config-ban regisztráljuk. Valahogy így:
<system.web>
  <pages>
    <controls>
 <add tagPrefix="asp" namespace="System.Web.UI" assembly="System.Web.Extensions, Version=1.0.61025.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"/>
        <add namespace="AjaxControlToolkit" assembly="AjaxControlToolkit" tagPrefix="ajaxToolkit"/>
    </controls>
  </pages>
 
Az első assembly az ASP.NET AJAX-os vezérlőkhöz kell (pl.: ScriptManagerProxy, UpdatePanel, UpdateProgress). A másik regisztráló rész a már említett AJAX Control Toolkit. Az assembly attribútumoknál azért van eltérés, mivel az AJAX Extensions szerelvénye bekerül a Global Assembly Cache-be (system32), míg a Control Toolkit assembly-je az alkalmazás Bin mappájába kerül. (Zárójelek között jegyzem meg, hogy az AjaxControlToolkit.dll-en kívül még a lokalizációhoz szükséges egyéb nyelvspecikikus dll-ek is bekerülnek a Bin mappába).
Az AJAX Control Toolkit-ről hamarosan sokkal bővebben…
 

13.fejezet, avagy a COMponens

Posted: 2007. augusztus 14. in exam 70-536
Chapter XIII. Interoperation (Interoperation)
 
Com és Unmanaged code. Két gyönyörű témakör, amelyekről lehetne órákon és órákon át beszélni/írni, de én inkább most csak a COM-mal foglalkoznék.
Régebben írtam még egy olyan webalkalmazást, amely úgy készített web-re diagramokat, hogy a háttérben megnyitotta az Excel-t, majd az ott elkészített diagramból kreált egy képet, és azt jelenítette meg. Sajnos ezt a kódomat nem találtam meg, így egy valamivel egyszerűbb példaalkalmazás keretén belül szeretném megmutatni az Excel használatát webforms alatt.
A COM komponenshez való csatlakozást/kapcsolódást a .NET COM Interop szolgáltatása teszi lehetővé. Ez implicit módon létrehoz egy osztály interfészt a nyilvános metódusok, események, stb. -k eléréséhez. Amikor egy COM komponensre hivatkozunk, akkor ezt a hivatkozást valahol el kell tárolnia az alkalmazásunknak. Így a COM-hez létrejön egy assembly, mely belekerül a hívó alkalmazás ManiFest-jébe. (Bővebben a manifest-ről a 14. fejezetben!)
Nézzük, hogyan hozunk létre egy hivatkozást az Excel COM komponensünkre. Solution Explorer-ben a projekten jobb klikk add reference menüpont. A felpattanó ablakban válasszuk a COM fület, majd keressük ki a Microsoft Excell 11.0 Object Library-t. 11 a verziószáma a 2003-as Office-ban lévő Excelnek, így ha Vista alatt fejlesztesz, akkor az Office 2007-nek megfelelően a 12-es verzió számú objektum könyvtárat keresd ki.
 
Nos, a következő programot szeretnénk elkészíteni: ha a kliens szövegesen ad meg valamilyen matematikai műveletet (pl.: 5-7 vagy sin(30)), akkor az Excelt segítségül hívva kiszámítjuk a pontos értéket (double pontossággal!). Így adjunk a weboldalunkhoz egy beviteli mezőt, egy gombot és egy labelt. Én az alábbi módon neveztem el őket: txtbox_expression, btn_calc, lbl_result.
Váltsunk át a webformunk code-behind fájljára (f7). /Shift + F7 aspx fájlra ugrik, vagy ha azon volt, akkor a design és source nézett között vált! Az Alt + F7 segítéségel pedig az ablakok (aktív eszközök) között tudunk váltogatni alt+tab-nak megfelelő megjelenésben és módon!/ Implementáljuk az alábbi névteret (bár a tapasztalat az mutatja, hogy teljesen felesleges): Microsoft.Office.Interop.Excel
Hozzunk létre 3 object objektumot: egyet az excel alkalmazás egy példányához, egyet egy munkafüzethez, és egyet egy cellához. Külön függvénybe írjuk meg a kiszámítást így globális váltózóként hozzuk létre őket:
public partial class _Default : System.Web.UI.Page
{
    private object eapp;
    private object eworkbook;
    private object erange;
 
A Page_Load-ban inicializáljuk őket. Ehhez segítségül hívjuk a HttpServerUtilty osztály CreateObject metódusát mely egyetlen string paramétert vár, amely a programazonosítója. Így egy COM komponensből egy szerver oldali példányt tudunk létrehozni. Fontos, hogy object típust ad vissza, így castolni kell! Lássuk a kódot:
eapp = Server.CreateObject("Excel.Application");
eworkbook = (Microsoft.Office.Interop.Excel.Workbook)((Microsoft.Office.Interop.Excel.Application)eapp).Workbooks.Add(Type.Missing);
 erange = (Microsoft.Office.Interop.Excel.Range)((Microsoft.Office.Interop.Excel.Application)eapp).Cells[1, 1];
 
A kód szerintem teljes egyértelmű, hogy mit csinál, ezért inkább csak két alternatívát mutatnék.
A Type.Missing helyett létrehozhattunk volna, egy object-et, amelynek a Missing.Value értéket adjuk értékül. Ezzel ugyanazt érjük el, mint a Type.Missing-gel, csak ilyenkor a System.Reflection névteret is using-olnunk kell.
 
object miss = Missing.Value;
eworkbook = …).Workbooks.Add(miss);
A másik dolog az, hogy ha nem globálisan hozzunk létre a változókat, tehát a Page_Load-ba írunk meg mindent, akkor akár így is írhatjuk a kódot:
Microsoft.Office.Interop.Excel.Application ObjExcel = new Microsoft.Office.Interop.Excel.Application();

Tehát nincs is feltétlenül szükségünk a HttpServerUtility osztályra.
 
Még két dolog van hátra, amit meg kell írni: a számolás, illetve a végeredmény megjelenítése. Kezdjük először a számolással. Hozzunk létre egy Calculate függvényt:
protected double Calculate(string command)
{
    ((Microsoft.Office.Interop.Excel.Range)erange).FormulaArray = "=" + command;
    double result = Convert.ToDouble(((Microsoft.Office.Interop.Excel.Range)erange).Value2);
    ((Microsoft.Office.Interop.Excel.Workbook)eworkbook).Close(false, Type.Missing, Type.Missing);
    ((Microsoft.Office.Interop.Excel.Application)eapp).Quit();
    return result;
}
 
Először azt csinálja a kód, hogy a beírt matematikai kifejezés elé beszúr egy egyenlőségjelet, így a cella value2 tulajdonsága segítségével le tudjuk kérni a kiszámított értéket. Majd bezárjuk a munkafüzetünket és végül az excel példányunkat is.
Végül jelenítsük meg az végeredmény:
protected void btn_calc_Click(object sender, EventArgs e)
{
    lbl_result.Text = Calculate(txtbox_epxression.Text).ToString();
}
 
És készen is vagyunk. Íme egyben a teljes alkalmazás programkódja: Check this out
 
 
Mivel sajnos nem a diagramos példaalkalmazást mutattam meg, ezért elégtételül egy-két linket adok a diagram(chart) készítés rejtelmeihez(bár ezeknek már semmi köze a COM-hoz):
A Look at WebCharts, a Free .NET Charting Controlhttp://aspnet.4guysfromrolla.com/articles/120804-1.aspx
Roll your own ASP.NET Chart Controlhttp://www.codeproject.com/aspnet/webchart.asp
Create Snazzy Web Charts and Graphics On the Fly with the .NET Frameworkhttp://msdn.microsoft.com/msdnmag/issues/02/02/ASPDraw/
 
 

13. – 14. fejezethez alapok II. rész

Posted: 2007. augusztus 10. in exam 70-536
.NET Alapok II. forduló
 
Az előző részében a sorozatnak megnéztük mi is körülbelül az a .NET. Most azt fogjuk megnézni, hogy a fontosabb részei hogyan is működnek, illetve miként kapcsolódnak a kódunkhoz.
 
 
.NET Futtatókörnyezet
A .NET Framework két legfontosabb része kétség kívül a CLI(Common Language Infrastructure) és a CLR(Common Language Runtime). Nézzük meg mit foglalnak ezek magukba!
 
CLI
A Common Language Infrastructure a különböző programozási nyelven írt programok futtatására szolgáló alrendszere a .NET Keretrendszernek. A megjelenése előtt minden nyelvnek saját futtató modulja volt, hogy a lefordított alkalmazás működhessen. A közös futtathatóságot úgy érték el, hogy minden nyelvet egy úgynevezett CIL(Common Intermediate Language) vagy MSIL (Microsoft Intermediate Language) nyelvre fordítanak le. Erről kicsit később.
A CLI egy osztálykönyvtárat és egy virtuális gépet használ. Az osztálykönyvtár jelen esetben a Base Class Library, a virtuális gép pedig a CLR a Common Language Runtime. Itt is látható a Java-féle koncepció, hiszen ők is egy virtuális gépet (Java Runtime Enviroment/ Java Virtual Machine) használnak a lefordított java bytecode futtatásához.

CLR
Először is tekintsük meg az alábbi ábrát, amely azt próbálja reprezentálni, mennyire is összetett a Common Language Runtime.

 

Ezt a sok-sok mindent, alapjában véve 4 alrendszerre lehet felosztani (a számozás nem a fontossági sorrendre utal!):
<1> Common Type System (CTS) – egységes típus rendszer, azokat a .NET típusokat definiálja, amelyek az alapjai a CLR működésének. Ő garantálja az összes implementált nyelv képes legyen futni .NET platform alatt, aminek az alapja a közös típusrendszer. Tehát minden nyelv innen veszi a típusokat, csak más aliaszként hivatkozunk rá (pl.: System.Int32 C# alatt int, Basic alatt Integer). A CTS felölős ezen kívül a típusok átjárhatóságáért (konvertálás). Minden, ami a CTS-ben van: objektum! Így minden a System.Object-ig visszavezethető. Kétfajta típus létezik: érték és referencia.
<2> Common Language Specification (CLS) – általános szabályokat fogalmaz meg, melyeket a .NET nyelvnek be kell tartaniuk. Ennek köszönhető a nyelvfüggetlenség, így a .NET alkalmazásainkat bármilyen nyelven is írjuk az eredmény elméletben ugyanaz.
<3> Just-In-Time Compiler (JIT) – Ez az IL kódról natív kódra fordító rendszer, de erről kicsit később.
<4> Virtual Execution System (VES) – virtuális futtató rendszer, mely a CLI parancsot végrehajtja, kezeli memóriát, stb. Összességben a CLR az alábbi 3 szolgáltatást nyújtja nekünk: kódellenőrzés (code verification), kódbiztonság (code access security) és hulladékgyűjtés (garbage collection). Ez az alapja a menedzselt kódnak.
  
Tehát összefoglalva a CLR igazi előnye, hogy a fejlesztésre magára lehet koncentrálni, nem kell platform- vagy gép- specifikus kódot írnunk.

Fordítási modell
Ismét kezdjük most is ábrákkal, egyből 2-vel:

 

 

Tehát ahogy az ábrákon is jól látszik az a következő folyamat játszódik le. Először is a forráskódunkból készül mindenféle fordító segítségével egy IL kód, ami bájtkód. Fontos megjegyeznünk, hogy ez még nem gép-specifikus kód. Ezeket úgynevezett szerelvényekbe fordítjuk le, amik vagy ddl vagy exe kiterjesztésük. Ez történik fordítási időben.
Futásidőben az IL kódunkat odaadjuk a CLR-nek, amely felügyeli a kódot (lentebb bővebben), majd a JIT segítségével natív, gépi-kódra alakítja, amelyet már a rendszer képes végrehajtani.
 
JIT
A JIT fordítás, Just In Time Compilation futás idejű fordításként vagy dinamikus fordításként is ismert, amely bájtkód-fordított rendszerek teljesítményének növelésére szolgáló technika. Mint ahogy föntebb is volt a bájtkódot alakítja natív kódra. Ez azért jó, mert így az IL kódunk hordozható és csak futtatáskor vagy telepítéskor fordul gép-specifikus kóddá. Ezt meg lehet fájl vagy függvény alapon tenni: a függvényeket akkor szükséges csak lefordítani, amikor végrehajtásra kerülnek (innen jön a "just-in-time", éppen időben kifejezés).
Célja egyértelműen a bájtkód és a natív kód előnyeinek egyesítése. A forráskód feldolgozása, alapvető optimalizálása, fordítási időben történik. A bájtkódról gépi kódra történő fordítás jóval gyorsabb, mint forráskódról.
Háromféle JIT fordításról szokás beszélni:
„Econo” JIT, amely optimalizálatlan natív kódot állít elő, így eldobható, újragenerálható. Ezért lehetséges az Edit&Continue
„Standarad” JIT, amely optimalizált  kódot generál, és verifikálja az IL kódot
Fordítás telepítéskor, amely futás előtt végrehajtódik, de a natív-kódban verzió ellenőrzés van, így vissza tud állni JIT-re, probléma esetén. Előnye egyértelműen a gyorsabb indulás
Menedzselt kód
Jó szokás az ábranézegetés, ne törjük meg sort, íme ismét két folyamat ábra:

 

 

A menedzselt kód a .NET együtt jött, így szinte minden más kódot unmanaged code-nak nevezünk. A Fordítási modell-es ábrán látható volt, hogy egyedül csak a C++ képes unmanaged code-ot előállítani, vagyis a fordító képes egyből natív kódot előállítani. A többi nyelv (C#, Basic, J#, stb..) csak menedzselt kódot képes generálni. (szokás még felügyelt, kezelt kódnak is hívni).
A felügyelet ugyebár a CLR feladata. A felügyelet két részre tagolódik: van a kódmenedzselés, és van az adat kezelés.
A menedzselt kód verifikálva van. Vagyis kötelező a metaadatok megadása (assembly-knél erről bővebben). Szigorú típusellenőrzés van, paramétereknél illetve visszatérési értékeknél is. Ez által megszűnnek az olyan típus hibák, mint az inicializálatlan változók, tömb túl indexelése, …  Illetve megjelenik a kód szintű kivételkezelés (try-catch)!
A menedzselt adatnál élettartam felügyelet van, vagyis van memóriakezelés is. Így a feleslegessé vált objektumokat a Garbage Collector összegyűjti és meghívja a destruktorukat. Illetve nem lesznek elfelejtett pointerek sem.
A mendezselt kód végrehajtásakor nagyon sok minden automatikusan megtörténik. A megfelelő szerelvények, osztályok beolvasása (assembly loader, class loader), mindenféle jogosultság kezelés (rbs, cas, ip) és végül fordítás natív kódra (jit), verifikálással együtt.
 
 
Hát valahogy így működik a .NET nagy vonalakban. Érdeklődve várom a visszajelzéseket afelől, hogy mennyire sikerült érhetően elmagyaráznom a .NET felépítését és müködést!
 

13. – 14. fejezethez alapok I.rész

Posted: 2007. augusztus 9. in exam 70-536

Chapter XIII. Interoperation (Interoperation) – Chapter XIV. Reflection (Reflexió)

Senki ne ijedjen meg, nem fogom egy cikkben tárgyalni ezt a két fontos fejezetet. A címben azért szerepel még is mindkét fejezet, mivel ahhoz hogy megértsük, mi is az a COM, unmanaged code, assembly, native codem fontos látnunk, hogy mi is az a .NET és hogyan is működik. Ezért egy kétrészes sorozatban, egy amolyan felvezetőként, megpróbálom elmagyarázni a .NET-et nagy vonalakban.

.NET története

A .NET körülbelül hét éve van köztünk. Vagyis 2000-ben kezdtek el róla nyilvánosan is beszélni. Valójában 1998-ban kezdődtek el a fejlesztést, amikor elhatározták, hogy nem használják tovább a Sun Java technológiát, hanem a saját MS J++ terméket fogják felhasználni a .NET projekt alapjaként. Eredetileg a neve sem .NET keretrendszer volt, hanem Common Object Runtime. Végül 2002.01.05.-én megjelent a .NET első verziója, a .NET Framework 1.0 és vele együtt a Visual Studio 2002.

Mi is az a .NET?

A .NET-re ezeregyfajta meghatározás van, hogy mi is valójában, de igazándiból senki se tudja. Ezért csak körülírni szokás. Íme egy rövid ugyanakkor tömör meghatározás: egy gyors alkalmazásfejlesztést (RADRapid Application Development), platformfüggetlenséget és hálózati átlátszóságot támogató szoftverfejlesztői platform.
A .NET által támogatott nyelvek az alábbi programozási paradigmákat „használják”:
objektum-orientáltság: lényege, hogy objektumokkal képezed le a világot, ezeknek van állandó belső állapota, és operációi, amiket más objektumok meghívhatnak.
esemény-vezéreltség: az objektumoknak vannak eseményeik, és ezek bekövetkezésekor hajtódnak végre a kódok. Alapjában véve kétfajta esemény van: Változás, Akció.
deklaratív/imperatív programozás: a deklaratív nyelvnél(SQL, ASP.NET) a kóddal meghatározzuk a célt a fordító vagy futtató rendszernek, míg az imperatív nyelvek(C#, Basic, Pascal) esetén inkább úgymond elmagyarázzák, mit kell csinálni a számítógépnek a kívánt cél eléréséhez.
reflexív programozás: futásidőben képes vizsgálni a kód szerkezetét, felépítést és ezt képes akár módosítani is. Ezt, maga a framework támogatja.
-… (pl.: komponens-orientált programozás)
Ezek (és még egy jó pár) programozási paradigma segítette a .NET fejlesztőit abban, hogy az elvárásaiknak megfeleljen a .NET platform. Az alábbi elvárásokat támasztották a keretrendszerrel szembe:
Átjárhatóság a COM és a .NET komponensek között, közös futattó/fordító környezet, nyelv függetlenség, alap osztály könyvtár, egyszerű terjesztés/telepítés, és persze a biztonság, stb..

Több fejlesztői segédeszköz is rendelkezésünkre áll, kifejezetten a .NET platformon történő fejlesztéshez. A legfontosabb a Visual Studio .NET, a Microsoft által nyújtott integrált fejlesztő környezet (IDEIntegrated Development Enviroment).

Miből épül fel a .NET keretrendszer? 

Nézzük meg nagy vonalakban, hogyan is épül fel a .NET Framework (alul-fölfelé kell nézni)
C# – Basic – J# – C++
Common Language Specification (CLS)
ASP.NET – Winforms
Adatok – XML
Base Class Library (Alap osztályok)
Common Language Runtime (CLR)

És ezt az egészet öleli körül a Visual Studio. Az alábbi ábra ugyanezt szemlélteti, MSDN konferenciák egyik kedvenc diája:

A következő részében a sorozatnak megfogunk ismerkedni a .NET futtatókörnyezettel (CLI/CLR), meg vizsgáljuk a fordítási modellt (JIT) és végül megnézzük mi fán terem a menedzselt kód.

 

Mcp, avagy milyen is egy vizsga.

Posted: 2007. augusztus 3. in Egyéb
A blogomban már sok mindenről írtam, aminek köze volt a vizsgákhoz, de magukról a vizsgákról még nem esett szó. Most pótlom ezt a hiányosságom.
MCP-ről úgy általában

Az MCP kétfajta rövidítést is takar. Az egyik a Microsoft Certification Program, ami egy olyan vizsgaazonosító szerűség. Ez azt jelenti, hogy minden cégnek, vállalatnak más és más, ami a vizsgák számozásában is látszik. Az MS-es vizsgák mind 70- -el kezdődnek.
A másik pedig a Microsoft Certified Professional, ami egy személyre vonatkozik. Ez körülbelül annyit tesz, hogy MS elismeri, hogy értesz az adott Technológiához, Szoftverhez, így álláskeresésnél az mcp vizsgák jó pontot jelentenek. Amiben egy adott témakörben több mcp vizsgával is rendelkezel, akkor az természetszerűleg egy magasabb szintű képzettséget von maga után. Az alábbi minősítésekhez általában 2-3 vizsga elég:
MCTSMicrosoft Certified Technology Specialist
MCITPMicrosoft Certified IT Professional
MCPDMicrosoft Certified Professional Developer
MCDSTMicrosoft Certified Desktop Support Technician
MCSAMicrosoft Certified Systems Administrator
MCSEMicrosoft Certified Systems Engineer
MCDBAMicrosoft Certified Database Administrator
MCADMicrosoft Certified Application Developer
MCSDMicrosoft Certified Solution Developer
http://www.microsoft.com/Learning/mcp/default.mspx
http://www.microsoft.com/learning/mcp/mcp/default.mspx

 
 
Magáról a vizsgáról
 
Azok, aki vizsgakupont kapta MS-től (Lipitől), csak a TrainerC Kft-nél(kis reklám) tehetik le a vizsgát. Az oktatóközpontjuk, ahol vizsgázni lehet Óbudán a Szentendrei út 39-53-ban van. Őszintén szólva nem egyszerű megtalálni az épületet, ezért egy kis segítség. A 86-os busz végállomástól, tehát a Bogdáni úttól, úgy lehet eljutni, hogy átmész u alakban a zebrákon. Majd az esso-val szembe lesz egy 3 emeltes, szürke kerítéses épület. Itt megkeresed a bejáratot, majd felbattyogsz az első emeletre. A többi innen már menni fog.
Szóval a vizsga előtt elolvastatják veled a halálos ítéleted (angolul) és aláírod, hogy minden vagyonodat rájuk hagyod. Ez után minden nevű eszköztől megszabadítanak, ami nem ruhanemű(eladják piacon, amíg Te vizsgázol).
A vizsgateremben egyszerre 4 ember fér el, és mindenkit figyelnek kamerával, illetve mikrofonokkal. Így kizárva a beszélgetés lehetőségét. A vizsgára kapsz egy lemosható táblát, nevezzük inkább fecninek, amire firkálsz a vizsga alatt.
Többféle vizsgaidő létezik. A neten például van ahol 3 órát írnak, van ahol 90 percet. TrainerC-nél ez 2 óra. + hozzájön a 15 vagy 30 perc, ha nem anyanyelved az angol. Tehát összességében 150 perced van vizsgára. A vizsgakérdéseket ott helyben állítja össze a szoftver, így mindenki mást ír. A kérdések száma sem mindig azonos, általában 45-60db.  A vizsgaideje alatt el lehet hagyni a termet, de attól az óra megy tovább!
A vizsgák általában 5-7 témakört ölelnek át. Például a 70-528 az alábbiakat
– Creating and Programming a Web Application
– Integrating Data in a Web Application by Using ADO.NET, XML, and Data-Bound Controls
– Creating Custom Web Controls
– Tracing, Configuring, and Deploying Applications
– Customizing and Personalizing a Web Application
– Implementing Authentication and Authorization
– Creating ASP.NET Mobile Web Applications
 
A 70-536 pedig:
– Developing applications that use system types and collections (15 %)
– Implementing service processes, threading, and application domains in a .NET Framework application (11 %)
– Embedding configuration, diagnostic, management, and installation features into a .NET Framework application (14 %)
– Implementing serialization and input/output functionality in a .NET Framework application (18 %)
– Improving the security of the .NET Framework applications by using the .NET Framework 2.0 security features (20 %)
– Implementing interoperability, reflection, and mailing functionality in a .NET Framework application (11 %)
– Implementing globalization, drawing, and text manipulation functionality in a .NET Framework application (11 %)
Bővebb infó a könyv első lapjain, illetve a vizsgák oldalán.
 
 
Vizsga kérdések
 
A vizsga legelején ki kell választani, hogy C# vagy Basic nyelven jelenjenek meg a kód részletek. Némelyik kérdéshez tartozik melléklet (kép, kódrészlet) is, ilyenkor az Exhibtion gombra kell ráplatyantani. Lehetőség van minden kérdésnél arra, hogy megjelöljük későbbi olvasásra, ilyenkor a felül a Mark for review checkbox-ot használjuk. Bár igazándiból nem túl sok értelme van, mert szabadon lehet járkálni a kérdések között azután, hogy mindegyikre adtunk valamilyen választ, de azért érdemes használni magunknak emlékeztetőnek.
A kérdések nehezebbek, mint a könyvben lévők. Az is nehezíti a dolgot, hogy sok olyan kérdés van, amikor egy folyamatot kell összeállítani, vagy pedig a lehetséges válaszok közül (ami akár lehet 8 is!) a legjobbat kell kiválasztani. Ezért ha egy adott eljárásra tudunk más alternatívát is, mint ami könyvben, azt felejtsük el a vizsgára (pl.: Page.Header.Title van a könyvben, de a Page.Title is ugyanúgy jó a való életben).  
A sikeres vizsgához 70%-ot, vagyis 700 pontot kell elérni. A vizsga eredményét 1 perc kalkulálás után megjeleníti a számítógép. Utána nyomtatott papírt is kap az ember.
 
 
Hogyan készüljek?
 
A vizsgára való felkészülésre, mindenki van egyedi bevált (vagy kevésbé bevált) módszere, így csak néhány hasznos tanácsot adnék.
– Ne legyünk könnyelműek abból a szempontból, hogy a nehezebb részeket hanyagoljuk a könyvben
(pl.: 528-ban: template (user) controls, healthmonitoring, impersonating, deployment, asynchronous, stb.,
536-ban: unmanaged code, generics, com, reflection, appdomain, stb.)
– Készítsünk jegyzetet, illetve az addig ismeretlen angol szavakat is írjuk ki! Vizsga előtt érdemes átolvasni.
– A labor gyakorlatok elvégzését, azoknál a fejezeteknél ajánlom kifejezetten, ahol sokat kell kattintgatni (így elméletben jobban rögzül)
 
Azoknak, aki nem készítettek jegyeztek, vagy úgy gondolják, hogy egy rövid összefoglaló nem árthat, nekik ajánlom Pallos Peti jegyzeteit:
70-528: https://wiki.sch.bme.hu/bin/view/Valaszthato/MCP70-528
70-536: https://wiki.sch.bme.hu/bin/view/Valaszthato/MCP70-536Jegyzet
 
Remélem sikerült ismét valamivel hozzájárulnom a sikeres vizsgákhoz.
 
 
 Mindenkinek jó és eredményes vizsgázást kívánok!