Кратко съдържание

Асемблита

За разлика от неуправляваните изпълними файлове, асемблитата са самоописващи се и носят в себе си информация за всички класове, типове и ресурси, които съдържат, както и информация за сигурността, за зависимост от външни компоненти и др. Тази информация се нарича метаданни.

Асемблитата имат собствена версия и дефинират изисквания към правата, свързани със сигурността, на потребителя или процеса, който ги изпъл­нява. Те могат да имат и цифров подпис, положен от създателя им, чрез който се осигурява повишена сигурност.

Проблемът "DLL Hell"

Например при Win32 приложенията може да се случи при инсталиране на нов софтуер част от старите приложения, които са работели до този момент, да спрат да работят. Причината е в това, че новият софтуер презаписва някоя от библиотеките, които старите приложения са изпол­звали, с по-нова версия, която може да не е съвместима със старата.

Тъй като при асемблитата версията се задава за всяко едно от тях и се записва освен в метаданните на асемблито и в неговото файлово име, при поява на нова версия не се появяват конфликти между приложенията.

Всяко асембли може да посочи точно кое асембли му е необходимо и точно в коя негова версия. Освен, че могат да съществуват едновременно няколко различни версии на едно асембли, те могат и да се изпълняват едновременно. Така е възможно в един и същи момент да работят и старите и новите приложения и всяко приложение да използва версията на общите асемблита, с която е предвидено да работи.

Всяко асембли съдържа т. нар. манифест, в който се описват зависи­мостите, които има с други асемблита. В него се определя и политиката за избор на версия, в случай че има повече от една за някое от реферира­ните асемблита.

Метаданни

• 
  име на асемблито (например System.Windows.Forms)
  
• 
  версия, състояща се от 4 числа (например 1.0.5000.0)
  
• 
  локализация, описваща език и култура (например неутрална или en-US или bg-BG)
  
• 
  цифров подпис на създателя (незадължителен)
  
• 
  изисквания към правата за изпълнение
  
• 
  зависимости от други асемблита (описани с точното име и версия)
  
• 
  експортирани типове
  
• 
  списък със дефинираните класове, интерфейси, типове, базови класове, имплементирани интерфейси и т.н.
  
• 
  списък с дефинираните ресурси
  

• 
  описание на член-променливите, свойствата и методите в типовете
  
• 
  описание на параметри на методите, връщана стойност на метода за всеки метод
  
• 
  приложени атрибути към асемблито, методите и другите елементи от кода
  

IL код

Във всяко асембли може да има секция, в която се намира неговият из­пълним код (IL кодът). Тази секция не е задължителна. Вече разгледахме какво представлява IL кодът и как се изпълнява, така че няма да се спираме отново на това.

Ресурси

В ресурсната секция на асемблито могат да бъдат добавяни различни ресурси (иконки, картинки, локализирани низове и др.), необходими на приложението. Ресурсите могат да се пакетират във файла на асемблито, заедно с изпълнимия код и могат да се извличат от него по време на изпълнение. Тази секция не е задължителна.

За удобство имаме възможност да създаваме и асемблита, които се състоят от няколко файла, както и сателитни асемблита с различна култура. Ще разгледаме асемблитата по-детайлно в темата "Асемблита и разпространение".

Разгръщане на асемблита

Тъй като асемблитата са основната единица за разгръщане (deployment) в .NET Framework, ще се спрем накратко върху различните видове асемблита според начина им на разгръщане – частни и споделени.

Частните асемблита (private assemblies) се използват само от едно приложение и се записват в неговата директория или в нейна поддиректория. Те са лесни за разгръщане тъй като могат да се разпрост­раняват чрез просто копиране и вмъкване (copy/paste). При тях контролът на версиите е по-лесен и не се изисква цифров подпис на създателя или силно име.

Споделените асемблита от своя страна са достъпни за всички приложения. Те се инсталират в специална област, наречена Global Assembly Cache (GAC). Всяко приложение, което реферира външно асембли търси споделените асемблита в тази област. Това поведение може да се контролира чрез манифеста, който задава правилата за търсене на нужните асемблита и версии. За да се определи уникално всяко асембли използва т. нар. силно име (strong name). To включва:

• 
  име на асемблито
  
• 
  версия
  
• 
  локализация
  
• 
  цифров подпис на създателя
  

Пример за силно име на асембли е идентификаторът:

["myDll, Version=1.0.0.1, Culture=neutral, PublicKeyToken= 9b35aa32c18d4fb1"]

Повече за разгръщане на приложения и асемблита можете да намерите в темата "Асемблита и разпространение".

Каталог: dotnetbook
dotnetbook -> Кратко съдържание
dotnetbook -> Кратко съдържание

Изтегляне 9.03 Mb.

Сподели с приятели: