След като сте създали клас библиотека (class library) с два класа (Uchenik и KlasDascal), време е да компилираме асемблито. Във VB6, бихте компилирали компонента COM, но вече не работим под VB6. Работим под .NET Framework, и това означава, че ще компилираме асембли (assembly). Асемблито може да има разширение .DLL, но не в традиционния Windows API смисъл, нито COM DLL в смисъл на VB6. Много е лесно. Има отделно меню, наречено Build. След като кликнете меню Build, имате няколко избора. Понеже имате solution, с клас библиотека (class library - Shkola) и Windows апликация (ShkolaClient), вие ще видите опция за "build or rebuild the solution". Имате опция "deploy the solution". Имате опции за един проект само, за "batch build", за "Configuration Manager".

В .NET, можете да компилирате своите асемблита или в режим Debug или Release, или можете да създадете свой собствен режим (custom modes). Debug mode компилира в символна debug информация и не използва оптимизация. Release mode не компилира в символна debug информация, а прилага оптимизационен код. Вие ще използвате режим Debug докато развивате и тествате вашата апликация, а когато сте готови ще превключите на режим Release и ще рекомпилирате своето асембли (assembly). Можете да реализирате свой собствен режим, примерно да модифицирате Release, като му добавите възможност за debug информация (Debug option). Падащият списък Solutions Configuration ви позволява да изберете Debug или Release, и да отворите Configurations Manager. Вижте Фигура 67.

Засега маркирайте проект Shkola в прозореца Solution Explorer.

След това в меню Build изберете Build Shkola. Прозорец Output в долната част на IDE ще ви съобщи дали компилацията е успешна.

Процесът на компилация създава два файла. Локацията по подразбиране за проекта е My DocumentsVisual Studio ProjectsShkola. Вие сте избрали ваша локация. Ако погледнете в папка Shkola, ще видите bin папка. Вътре в папка bin има два файла: Shkola.dll и Shkola.pdb. Асемблито е .DLL, а .PDB е debug файла, защото компилацията е в режим Debug. За базата данни на програмата (program database) е .PDB файла.



Фигура 68 Изпълнение на програмата в Debugger.


- Използване (Reusing) на асемблито в други апликации

Една от големите разлики между VB6 и VB.NET е, че асемблитата не използват регистри (registry). Фактически, VB.NET не поддържа някаква информация, която бихте намерили за Shkola асембли. Ще намерите информация за проекта и решението (solution), но в registry няма нищо за асемблито. Как тогава то се използва в друга Windows апликация? Ако стартирате нов проект Апликация под VB.NET и с десен бутон на мишката върху разклонение References в прозореца Solution Explorer покажете диалога Add Reference, компонента Shkola няма да се разлисти.

Това не толкова сюрпризиращо; той се показва по-рано, защото ShkolaClient беше част от същото решение. Сега вие стартирахте нов проект, който създава ново решение (solution). Това solution е в друга директория и затова не "знае" за компонент Shkola. За да може новия проект да използва компонент Shkola, в страница .NET Framework на диалога Add Reference кликнете бутон Browse. Чрез навигация към папка My DocumentsVisual Studio ProjectsShkolabin или съответно вашата локация - изберете Shkola.dll. Сега вече разклонение References в прозореца Solution Explorer показва компонент Shkola. Вашата апликация сега може да използва този компонент. Можете да създадете обект така:

Dim Uchenik As New Shkola.Uchenik()

Можете да използвате команда Import , за да импортирате пространство от имена Shkola, така че да можете да инстанцирате обекти с този код:

Dim Uchenik As New Uchenik()



- Как .NET локализира асемблитата

.NET не използва registry, така че механизма за локация на асембли е друг.



Стъпка 1: Получаване на референтна (Reference) информация

Вашата апликация се опитва да извика свързано (referenced) асембли. Връзката (reference) съдържа следната информация за асемблито:

- Име (Name)

- Версия (Version)

- Култура (Culture)

- Публичен ключ (Public Key)

Средата за изпълнение (runtime) използва тази информация, за да се опита да локализира асемблито.



Стъпка 2: Преглеждане на конфигурационния файл (Configuration File)

Конфигурационния файл е мощна концепция. Можете да създавате конфигурационен файл за обработване на всяка референтна информация, която може да се промени. Примерно, ако се нуждаете от актуализация на конкретната версия на асемблито, използвано от апликацията, можете да съхраните информацията в конфигурационния файл. Можете да направите така, че апликацията да се свърже само с тези версии на компонентите, които са били на разположение, когато апликацията е била изградена. Това се нарича Safe Mode. Конфигурационния файл е XML файл.


Стъпка 3: Използване на CodeBases или Probing

Ако искате да предотвратите probing, може да спесифицирате стойност CodeBase в конфигурационния файл. Когато средата за изпълнение (runtime) зареди файла, който се указва от CodeBase, той проверява информацията за версиите, за да е сигурен че съвпада това което е в референцията на апликацията. По подразбиране, ако асемблито указано от CodeBase е същата версия или по-голяма, свързването ще се осъществи.

Ако няма CodeBase, runtime проверява първо в GAC дали асемблито е строго именовано (strongly named) (със силно име). Ако асемблито е private, търсенето се извършва само в кореновата директория на апликацията (root directory), референтна като AppBase. Средата за изпълнение (runtime) вижда reference към асемблито в апликацията, като Shkola, и гледа за асембли на първо търсене като Shkola.DLL. Ако асемблито не се намери в директория AppBase, средата за изпълнение (runtime) търси асембли, базирано на пътя (path) в конфигурационния файл. Този път е спесифициран с <AppDomain> tag:



<probing privatePath="MyAssemblies"/>

Средата за изпълнение (runtime) автоматично добавя в края друга информация към пътя за търсене. Например търси в:


AppBaseShkola.

или AppBasebin.

Защото сте спесифицирали MyAssemblies в <AppDomain> tag, търси и в: AppBaseMyAssemblies.

Накрая, ако локализацията е de, пътя за търсене ще включва:

AppBaseBinde, AppBaseShkolade, AppBaseMyAssembiesde.



Стъпка 4: Глобален кеш на асемблитата - GAC

Global Assembly Cache е кешът за асемблита, който се използва за много апликации на същата машина. Даже и асемблито да е намерено чрез probing или CodeBases, Средата за изпълнение (runtime) проверява за актуализирани версии в GAC. Ако съществува по-висока версия в GAC, тя се използва. Ако не е намерено асембли чрез CodeBase или probing, то средата за изпълнение (runtime) търси за съвпадение в GAC. Ако се намери асембли, то се използва.

За да прибавите (add) към, изтриете (remove) от, или визуализирате (view) в GAC асембли, използвайте конзолна апликация gacutil.exe, поддържана от Framework. Кешът GAC е също директория, така че може да добавяте асемблита и чрез копиране (copying) в GAC директорията.


Стъпка 5: И администратора поема

Възможно е за администратора да създаде файл, който спесифицира конкретната версия на асемблито, което се използва. Ако апликацията търси примерно версия 2.1.9.0 на Shkola, Administration policy file може да укаже на апликацията друга версия по-висока или по-ниска.