augusztus, 2007 havi archívum
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.
– 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.
– 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 reflectionPerm2 = new ReflectionPermission(ReflectionPermissionFlag.ReflectionEmit);
ReflectionPermission reflectionPerm3 = (ReflectionPermission)reflectionPerm1.Union(reflectionPerm2);
– 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.
.NET Security Blog : When is ReflectionPermission Needed? – http://blogs.msdn.com/shawnfa/archive/2005/03/08/389768.aspx
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 Do – http://www.devx.com/dotnet/Article/28490?type=kbSampleProd&trk=MSCP
Real-world Reflection in .NET – http://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
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.)!
<%@ 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 AJAX Control Toolkit-ről hamarosan sokkal bővebben…
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.
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:
{
private object eapp;
private object eworkbook;
private object erange;
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 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.
…
Tehát nincs is feltétlenül szükségünk a HttpServerUtility osztályra.
{
((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;
}
Végül jelenítsük meg az végeredmény:
{
lbl_result.Text = Calculate(txtbox_epxression.Text).ToString();
}
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!
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.
<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.
Fordítási modell
Ismét kezdjük most is ábrákkal, egyből 2-vel:
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.
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
Jó szokás az ábranézegetés, ne törjük meg sort, íme ismét két folyamat ábra:
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.
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 (RAD – Rapid 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 (IDE – Integrated 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.
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:
MCTS – Microsoft Certified Technology Specialist
MCITP – Microsoft Certified IT Professional
MCPD – Microsoft Certified Professional Developer
MCDST – Microsoft Certified Desktop Support Technician
MCSA – Microsoft Certified Systems Administrator
MCSE – Microsoft Certified Systems Engineer
MCDBA – Microsoft Certified Database Administrator
MCAD – Microsoft Certified Application Developer
MCSD – Microsoft Certified Solution Developer
http://www.microsoft.com/Learning/mcp/default.mspx
http://www.microsoft.com/learning/mcp/mcp/default.mspx
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
– 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 %)
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.
– 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)
70-528: https://wiki.sch.bme.hu/bin/view/Valaszthato/MCP70-528
70-536: https://wiki.sch.bme.hu/bin/view/Valaszthato/MCP70-536Jegyzet