Class Library Project

Amennyiben könyvtárat szeretnénk készíteni, úgy a File menü New\Project menüpontjában a Class Library típusú projectet kell kiválasztani.

Az ilyen jellegű project eredménye egy ’.dll’ kiterjesztésű fájl.

Az ilyen projectben nem lehet Main() függvény, hiszen egy ’dll’ önmagában nem futtatható. Más programok számára tartalmaznak segédosztályokat, metódusokat.

Könyvtár fejléce

Amennyiben könyvtárat szeretnénk készíteni, úgy a File menü New\Project menüpontjában a Class Library típusú projectet kell kiválasztani.

Az egyik legelső, amit ki kell töltenünk, az a ’dll’ fejrész információk. Ez régebben az AssemblyInfo.cs fájl tartalmának módosítását jelentette, a Visual Studio 2005-től a Project | Properties | Application | Assembly Information párbeszédablak mezőinek kitöltését jelenti.

A mezők ismertetése sajnos túlmutat e dokumentum keretein. De meg lehet adni a készítő cég nevét, szerzői jogi információkat, az assembly verziószámait, és a cég digitális aláírását.

Névtér kiválasztása

Egy assembly-ben jellemzően csak egy névtér található. Ebben helyezzük el az osztályokat, azokban a metódusokat.
A névtér nevének kiválasztásánál ügyeljünk arra, hogy bár a System névtér használható, de ez a névtér a .NET rendszert felépítő dll-ekre jellemző.
Ugyanakkor jellemzően a névtérben is a programozó cég vagy a programozó neve köszön vissza. Esetleg az assembly-ben tárolt kóddal kapcsolatos nevet választanak:
Pl.:
namespace HighSpeed.Software
{
}
A névtér neve tartalmazhat pontot is.
Próbáljunk a névtérnek olyan nevet választani, amelyet más, szintén assembly-ket előállító programozó talán nem fog választani. Egy nagy projektet sok assembly-ből kell összeállítani, és az egyforma névtér nevek bonyodalmakhoz vezetnek.

Osztályok létrehozása

Az assembly belsejében ugyanolyan stílusban és módon tudunk programozni, mintha hagyományos alkalmazást írnánk. Osztályokat hozhatunk létre, azokba mezőket, metódusokat készíthetünk.

Ügyeljünk arra, hogy az assembly belsejébe ne alakítsunk ki Main() függvényt, mivel ilyet assembly nem tartalmazhat.

Valamint ügyeljünk arra, hogy csak rendkívül indokolt esetben használjuk a Console osztályt (Console.Write(), Console.ReadLine(), stb.), mivel nem tudhatjuk előre, hogy az assembly-t milyen programozási környezetben fogják később használni. Amennyiben egy Windows-os programban vagy egy web-es programban tennék meg, úgy a konzolos kiírató és adatbekérő utasításaink nem működnének.

Leírások

Célszerű a könyvtár írásával párhuzamosan kommenteket (dokumentációs megjegyzéseket) is írni. Ezeket a /// jel mögé írjuk. Ilyenek készíthetők osztályokhoz, mezőkhöz, metódusokhoz.
A három perjel beírásakor a Visual Studio a megfelelő módon XML kommentekké alakítja azt:
Pl.:
/// <summary>
/// Ez itt a matematikai műveletek osztálya
/// </summary>
public class Matematika
{
/// <summary>
/// Kiszámolja egy szöghöz tartozó sinus értéket.
/// </summary>
/// <param name="x">A szög értéke radiánban</param>
/// <returns>A radiánban megadott szög sinusa</returns>
public static double Sinus(double x)
{
...
}
}
A summary részhez kell egy összegző, összefoglaló jellegű leírást megadni. A paraméterekhez mindegyikhez önálló leírás készülhet. A függvény visszatérési értékének magyarázatához a returns részt kell kitölteni.

Publikálás

A névterünkben osztályokat hozhatunk létre. Az osztályoknak két fajtája van:

• publikus osztályok: olyan osztályok, melyek ’kifelé’, a dll-en kívül is látszanak. Miattuk írjuk az assembly-t, mivel ezek az osztályok lesznek a főprogramban használhatóak.
• segédosztályok: csak belsőleg, az assembly belsejében használható osztályok.

A publikus osztályokat a public class módon kell létrehozni, vagyis a class elé oda kell írni a public szót.
A segédosztályok deklarálása egyszerűen class, mindenféle módosító nélkül.
Pl.:
public class Matematika
{
public static double Sinus( double x ) { ... }
}
class Seged
{
...
}

Publikálás problémái

Amennyiben egy osztályunk publikus, úgy konfliktus léphet fel egyéb nem publikus osztályok felé:

• ha egy assembly-ben lévő osztály publikus, akkor az ős osztályának is publikusnak kell lennie
• ha egy assembly-ben lévő osztály publikus, akkor minden public vagy protected vagy internal protected mezőjének a típus-osztálya is publikus kell, hogy legyen
• ha egy assembly-ben lévő osztály publikus, akkor minden public vagy protected vagy internal protected metódus paramétereinek típus-osztálya is publikus kell, hogy legyen

Ezek ésszerű megkötések, ennek hiányában hiába lenne az osztály publikus, ha pl. nem tudnánk valamely mezőjére hivatkozni, mivel annak típusa nem publikus.
Pl.:
class Kerek
{
...
}
public class Auto
{
// hiba: a ’Kerek’ osztály a DLL-en kívül nem látszik
public Kerek balHatsoKerek;
}

Belső védelmi szint

Az assembly fájlokban lévő osztályokat védhetjük az által, hogy nem tesszük őket publikussá. Azonban a publikus osztályok esetén is hasznosítható két új védelmi szint került bevezetésre. Ezen védelmi szintek mezőkre és metódusokra helyezhetőek el, segítségükkel más-más védelmi szintre kerülhetnek a mezők vagy metódusok az assembly-n belüli kód, és az assembly-n kívüli kód szempontjából:

• internal: ezen jelzésű mező vagy metódus az assembly belsejében lévő kód szempontjából public, az assembly-n kívüli (felhasználói) kód szempontjából private minősítést jelent.
• internal protected: ezen jelzésű mező vagy metódus az assembly belsejében lévő kód szempontjából public, az assembly-n kívüli (felhasználói) kód szempontjából protected minősítést jelent.

Vegyük észre, hogy internal public nincs. Ez azt jelentené, hogy befelé és kifelé is public, de ezt az egyszerű public kulcsszó jelenti.

Fordítás

Amikor a class library projectet fordítjuk, az XML kommentek külön fájlba kerülnek be, amennyiben a PROJECT | PROPERTIES | BUILD párbeszédpanelen az XML DOCUMENTATION FILE részt kipipáljuk, és megadjuk azt a fájlnevet, amibe a dokumentációs megjegyzések kerüljenek (Visual Studio 2005-től).
Ezen dokumentációs fájlt a Visual Studio képes feldolgozni, amikor idegen assembly-t adunk a projecthez, és a benne lévő kommenteket a megfelelő időben tooltip formájában megjeleníteni.
Maga a kód a lemezen a projecthez tartozó bin\Debug alkönyvtárban keletkezik, .dll kiterjesztéssel. Másolható, terjeszthető.

Digitális hitelesítés

Az assembly fájlokba elhelyezhetjük a digitális hitelesítő aláírásunkat. Ezzel igazolhatjuk, hogy az assembly fájlt valóban mi készítettük. Ez igen hasznos, mivel az internetről letöltött assembly fájlok igen könnyen tartalmazhatnak hibás, vagy káros kódokat. Amennyiben a letöltő ismer és bízik a készítő cégben, ennek segítségével megbizonyosodhat arról, hogy az assembly megbízható forrásból származik.
A hitelesítő kódpárt egy ezzel foglalkozó cégtől kell igényelni. Amennyiben erre nincs lehetőségünk – gyárthatunk egy sajátot:
sn –k sajatAzonositom.snk
Az sn.exe a Visual Studio-val érkező kis segédprogram, amelyik legyártja a hitelesítéshez szükséges privát és publikus kulcsot.
Már csak annyit kell tenni, hogy a fenti publikus kulcs nevét meg kell adni az assembly beállításoknál.
AssemblyInfo.cs fileban:
[assembly: AssemblyKeyFile("sajatAzonositom.snk")]
vagy Visual Studio 2005-től PROJECT | PROPERTIES | SIGNING | SIGN THE ASSEMBLY részen.