След като сте създали клас библиотека (
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 Projects
Shkola. Вие сте избрали ваша локация. Ако погледнете в папка
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 може да укаже
на апликацията друга версия по-висока или по-ниска.