Асемблита и разпространение

Предимства и недостатъци на GAC

• 
  Единствено място за инсталиране на асемблита, които се използват от множество приложения. Много по-лесно е за инсталиране на нова версия на даден компонент в GAC и създаване на publisher policy file за пренасочване всички приложения да използват новата версия отколкото да се търсят всички копия в частните папки на различните приложения.
  
• 
  По-добро бързодействие при цифрово подписаните асемблита – това е така, защото проверката на цифровия подпис се прави веднъж – при инсталиране в GAC, докато при частните асемблита се прави на всяко зареждане.
  
• 
  По-добро бързодействие и спестяване на ресурси при зареждане на няколко копия от едно и също асембли – в такъв случай CLR просто пренасочва заявките към вече зареденото асембли, вместо да заделя памет и да зарежда асембли в паметта отново.
  
• 
  Решава проблема с DLL ада и позволява side-by-side execution.
  

• 
  Асемблитата, които се инсталират в GAC трябва задължително да са силно именувани.
  
• 
  GAC се намира в %systemroot%\assembly и като поддиректория на Windows се изискват администраторски права, за да се променя съдържанието му.
  
• 
  Директно копиране в GAC не е допустимо – асемблитата трябва да се инст­алират посредством някой от следните начини:
  
  • 
    Чрез Windows Installer 2.0.
    
  • 
    Чрез от инструмента gacutil.exe от .NET Framework SDK.
    
  • 
    Чрез Windows Shell разширението за Windows Explorer, съдържащо се в SHFusion.dll.
    
  • 
    Чрез административната конзола на .NET Framework – mscorcfg.msc.
    
  • 
    Чрез API функциите на класа Microsoft.CLRAdmin.Fusion от .NET Framework библиотеката mscorcfg.
    

Работа с GAC – пример

1. 
   Добавяме асемблито в GAC със следната команда:
   

   gacutil /i MyStrongNamedAssembly

2. 
   За да видим съдържанието на GAC използваме командата:
   

3. 
   За дерегистрация (изтриване) на асембли от GAC използваме следната команда:
   

Разпространение и инсталиране на програмни пакети

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

В зависимост от типа на приложението инсталационният пакет включва различни комбинации от съставните части на приложението: файлове и папки, асемблита, инсталационни компоненти, COM обекти, сървърни ком­поненти, бази данни, настройки на Internet Information Server и т. н.

Файлове и папки

Конфигурационни файлове

Например, ако в даден проект се разработват Windows приложение и уеб услуга, то в конфигурационния файл на Windows приложението ще се съхранява URL до тази уеб услуга. URL адресът обаче ще е различен при различните етапи на разработване, тестване, интегриране на системата и при реално функционираща среда. Необходимостта от различни конфигу­рационни файлове се отежнява и от факта, че за отдалеченото извикване (.NET Remoting) са необходими допълнителни настройки в конфигура­ционните файлове, които коренно се различават в различните среди и трябва да се тестват цялостно при използване на .NET Remoting техноло­гията.

Използване на конфигурационни файлове

За да се управляват по-лесно различите конфигурации, може да се използва следното решение:

1. 
   Добавяме конфигурационен файл, необходим за средата за разра­ботка към проекта във Visual Studio .NET (App.config или Web. config в зависимост от типа на проекта). Visual Studio .NET автоматично добавя Web.config при създаване на ново ASP.NET приложение.
   
2. 
   Създаваме отделен конфигурационен файл за всяка среда, където настройките се различават. Именуваме ги така, че от името им да става ясно за каква среда са необходими (напр. Test.Web.config, Production.Web.config ) и ги добавяме към проекта.
   
3. 
   Включваме само необходимия конфигурационен файл в зависимост от средата, в която ще се инсталира, и го преименуваме на изисква­ното име като част от инсталационния процес. Изискваните имена са .exe.config за Windows приложения или Web.config за уеб приложения.
   

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

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

Файлове за уеб услуги

Много от проблемите, засягащи инсталирането на уеб приложенията се отнасят и за уеб услугите – настройки на IIS, инсталиране на HTTP модули и обработчици (HTTP handlers).

Малка разлика между уеб приложенията и уеб услугите представлява видът на файловете. За уеб приложенията се инсталират предимно .aspx и .ascx файлове, докато уеб услугите изискват .asmx и .disco файлове.

XSD файлове

XSD файловете са документи, които служат за дефиниране и проверка на съдържанието и структурата на XML документи. Инсталиране на XSD файлове е необходимо само ако приложението има нужда от тях по време на изпълнението си. Например, ако метод разработен в уеб услуга връща като резултат силно типизиран DataSet, тогава XSD файлът трябва да се инсталира (заедно с ASMX и DISCO файловете), тъй като уеб услугата ще съдържа референция към него. Когато разработчиците разглеждат DISCO файла на тази услуга от Visual Studio .NET те ще могат да разгледат и схемата чрез връзката View Schema.

J# инсталационен пакет (J# Redistributable Package)

Инсталация на Visual J# .NET Redistributable Package (vjredist.exe) е необходима, ако приложението използва компоненти или библиотеки написани на Visual J#, понеже J# не е част от .NET Framework, а е допълнително разширение.

Асемблита

Инсталирането на многомодулни асемблита изисква наличието на всички модули. В противен случай използването на асембли с липсващ модул ще предизвика грешка.

Силно именувани асемблита

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

Едно от възможните решения е инсталиране на силно именуваното асем­бли в GAC. По-късно, при разработване на асембли с по-висока версия се разработва и Publisher Policy File, който описахме в точката за Конфигурационни файлове. Новото асембли и Publisher Policy File също се инсталират в GAC. По този начин всички приложения започват да изпол­зват новата версия на асемблито.

Частни асемблита

Ако дадено асембли е проектирано да се използва само от едно прило­жение, то трябва да се инсталира като частно асембли. Частните асем­блита обикновено се инсталират в папката на приложението. Други подходящи местоположения на частните асемблита са:

• 
  Директорията, съдържаща изпълнимия файл или нейна поддирек­тория.
  
• 
  Bin папката, намиращата се във виртуалната директория на уеб приложението или уеб услугата в IIS.
  
• 
  Местоположение описано с елемент в конфигурационния файл на приложението.
  

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

Частните асемблита се използват само от приложението, с което са инста­лирани. По този начин приложението е изолирано от останалия софтуер на машината. Това е един от начините да се избегнат проблемите с различните версии – т. нар. "DLL ад".

Споделени асемблита

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

• 
  Инсталиране на асемблито с всяко приложение като частно асембли – по този начин всяко копие е абсолютно независимо от останалите. Инсталирането на множество копия поражда определени проблеми, които следва да се вземат под внимание: възможно е да съществуват множество версии на асемблито, които дори използват различни версии на .NET Framework; при наличието на определени проблеми с асемблито, които са отстранени в следващи версии се създават трудности със замяната на всички копия на машината.
  
• 
  Инсталиране на асемблито в една обща директория – за всяко от използващите го приложения се посочва тази директория с елемента в конфигурационния файл. Ако се използва една директория за всички споделени асемблита на дадена компа­ния, се загубва възможността за side-by-side execution, но се решават проблемите с версионизиране на асемблитата (за да е възможен ъпгрейд на асемблита с просто копиране те не трябва да бъдат силно именувани). Трябва да се планира внимателно избор на подобна стратегия, защото, ако на следващ етап възникне изискване за използване на side-by-side execution, стратегията трябва да се смени, което ще доведе до трудности.
  
• 
  Инсталиране в GAC – препоръчително е при инсталиране на асембли в GAC да се изпълнява броене на референциите, за да се избегне премахването на асембли от GAC, докато все още съществува приложение на машината, което го използва. Съществуват два начина да се постигне това: чрез Windows Installer или чрез gacutil.exe (използват се параметри /ir за инсталиране и /ur за деинсталиране чрез броене на референциите).
  

Потребителски контроли тип Windows Forms (Windows Forms User Controls)

Потребителските контроли тип Windows Forms са асемблита, които могат да се извикват от уеб страници като се свалят на клиентската машина и се стартират локално на нея. По подразбиране такива контроли работят с нама­лени права, за да не застрашават сигурността на потребителя.

Инстали­рането на този тип контроли поставя известни предизвикателства, понеже те се изпълняват в контекста на правата, дадени им от уеб брау­зъра и от политиките за сигурност на .NET Framework.

От гледна точка на сигурността съществуват два вида потребителски контроли тип Windows Forms – такива, които се стартират с права по-подразбиране, и такива, които изискват по-високи права.

Контролите, които изискват по-високи права за изпълнение следва да бъдат силно именувани (strong-named) или цифрово подписани (digitally signed). Това позволява на администраторите да разрешат по-високи права на асемблита от дадена компания, без да компрометират сигур­ността.

Изискването за промяна настройките на сигурността прави контроли от този тип да бъдат по-лесни за използване в корпоративна Интранет среда, където администраторите на домейни централизирано могат да променят тези настройки. За да бъдат контролите използваеми през Интернет, потребителите трябва да следват определени инструкции, за да променят настройките на сигурността.

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

Инсталационни компоненти

Разпределените .NET приложения се състоят не само от традиционни програмни файлове и асемблита, но и от допълнителни ресурси като опашки от съобщения (message queues), логове на събитията (event logs), индикатори за производителността (performance counters) и бази данни (databases). Тези ресурси са необходими за нормалното функциониране на приложенията и като такива следва да бъдат създадени по време на инсталационния процес.

.NET Framework предоставя компоненти, които създават и конфигурират ресурсите по време на инсталация и ги изтриват по време на деинста­лация. Тези компоненти се интегрират с инстала­ционните инструменти (InstallUtil.exe) на Windows Installer и Windows Installer Service. Съще­ствуват два типа инсталационни компоненти: предварително създадени инсталационни компоненти и инсталационни класове (Installer Classes).

Предварително създадени инсталационни компоненти

Майкрософт предоставят пет предварително дефинирани инсталационни компоненти, които могат да бъдат използвани при създаване на инстала­ции за приложения:

• 
  EventLogInstaller – използват се при създаване и настройване на логове на събитията (event logs).
  
• 
  MessageQueueInstaller – използват се при създаване и настройване на опашки от съобщения (message queues).
  
• 
  PerformanceCounterInstaller – използват се при създаване и нас­тройване на индикаторите за производителността.
  
• 
  ServiceInstaller и ServiceProccessInstaller – използват се при създаване и настройване на Windows услуги.
  

Всеки един от тези класове се използва, за да се инсталират необходи­мите ресурси по време на инсталационния процес. След добавяне на определен компонент в дизайн изгледа на Visual Studio .NET има възможност за генериране на съответния инсталационен клас чрез контекстното меню на компонента, както е показано на картинката:

При добавяне на инсталационния компонент към проекта се създава клас, наречен ProjectInstaller, който съдържа инсталационните класове на всички компоненти използвани.

По време на инсталационния процес се задейства ProjectInstaller, който изпълнява инсталация за всеки от съдържащите компоненти.

Инсталационни класове (Installer Classes)

В някои случаи се налага да се инсталират ресурси, за които няма пред­варително създадени инсталационни компоненти. Може да се наложи да се изпълнят някои специфични действия по време на инсталационния процес. Добър пример за това е създаване на база данни, попълване на някои таблици и прекомпилиране на дадено асембли до native код (чрез инструмента NGen.exe) след успешно приключване на инсталацията. За тази цел могат да се използват класовете от пространството System. Configuration.Install и най-вече класа Installer, който се наследява за да се имплементира потребителски инсталатор за даден компонент.

COM базирани обекти

Възможно е в бъдеще компонентите, изградени с помощта на .NET Framework да заменят изцяло компонентите базирани на Component Object Model (COM, COM+, DCOM – за повече информация виж http://www.microsoft.com/com). Докато настъпи този момент, обаче, ще трябва да имаме предвид тяхното съществуване и да им отделим подхо­дящото внимание.

За да бъдат използваеми всички COM базирани компоненти, трябва да бъдат регистрирани на компютъра и да са инсталирани в COM+ каталога.

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

При инсталиране на COM базиран компонент трябва да бъде извършена регистрация в COM+ каталога (чрез regsvr32.exe или Windows Installer) и .NET приложението, което го използва трябва да има достъп до Interop асемблито, съдържащо дефиниции на типовете в COM обекта (генерира се чрез tlbimp.exe).

При инсталиране на асемблита, които ще се извикват през COM трябва да се извърши регистрация чрез .NET Framework SDK инструмента Assembly Registration Tool (regasm.exe).

При инсталирането на асемблита, които ще се извикват през COM имайте предвид, че ако асемблито няма да се инсталира в GAC, трябва да се използва параметъра /codebase при регистрация с Regasm.exe (или съответното настройване при Windows Installer, както ще видим в примера по-долу). В противен случай COM няма да може да открие местоположението на асемблито.

Сървърни компоненти (Serviced Components)

Сървърните компоненти, създадени с .NET Framework, разчитат на COM за предоставянето на компонентни услуги като управление на транзакциите (transaction management), пулинг на обекти (object pooling) и като цяло предоставяне на услуги, които се обуславят от COM технологията.

Сървърните компоненти се стартират като COM базирано приложение и затова те трябва да регистрират в COM каталога. Това налага следните инстала­ционни и конфигурационни изисквания за компонентните услуги:

• 
  Асемблитата трябва да са силно именувани.
  
• 
  Асемблитата трябва да са регистрирани в регистрите на Windows (Windows registry).
  
• 
  Библиотеката с типовете (type library) трябва да е регистрирана при клиента.
  

Динамична регистрация на сървърни компоненти

Сървърните компоненти често се регистрират динамично първия път, когато приложение се опита да ги използва. Тогава CLR регистрира асемблито, библиотеката с типовете и конфигурира COM+ каталога. Регистрация се прави само веднъж за дадена версия на асембли. Това е най-лесният начин за регистриране на сървърни компоненти, но за да е успешен процесът, който ги стартира, трябва да има административни права върху машината. Допълнително ограничение е фактът, че динамич­на регистрация е възможна само ако асемблито се извиква от управляван код. Ако извикването се прави от неуправляван код, динамич­ната реги­страция не е възможна.

В много случаи процесът, който извиква асемблито, няма изискваните права, за да извърши динамична регистрация. Пример за това са компо­ненти, които се извикват от уеб приложение. Такива компоненти не могат да бъдат регистрирани, защото ASP.NET процесът няма администра­тивни права (освен ако не е настроен да се изпълнява в контекста на потре­бителя SYSTEM, което не е добра идея и компрометира сигурността). В такъв случай регистрацията ще се провали ще се предизвика грешка „отказан достъп” (access denied). Затова трябва да направим необходи­мата регистрация по време на инсталационния процес.

Регистрация на сървърни компоненти при инсталация

Понеже сървърните компоненти използват предимствата на COM+ услуги­те, те имат същите изисквания относно инсталацията:

• 
  Комуникацията със сървърните компоненти се осъществява през DCOM по подразбиране. Поради тази причина Interop асемблитата трябва да се регистрират на клиентската машина.
  
• 
  В допълнение към COM+ настройките, които се правят декларативно при разработката на асемблито с помощта на атрибути (виж [TODO: връзка към глава атрибути]), трябва да осигурят, че конфигура­ционните настройки (като присъединяване на потребители към потребителски групи, настройване на подходящи права за изпълне­ние, задаване в кой контекст на сигурност (security context) ще се изпълнява процесът) са подходящо създадени и компонентът е готов за използване. Това може да бъде постигнато чрез добавяне на скрипт към допълнителните действия (custom actions) на Windows Installer, който да регистрира компонента.
  

Възможно е настройването на COM+ приложението да използва SOAP вместо DCOM. Това заобикаля изискването да се инсталират Interop асемблита на клиентската маши­на. Този метод не позволява да се използва създадената от DCOM транзакция клиент-сървър и трябва да се добави допълнителен код, който да управлява транзакциите.

Настройки на Internet Information Server (IIS)

ASP.NET приложенията изискват наличието на Internet Information Server (IIS), за изпълнението си. В някои случаи е необходимо да се правят промени по настройките на IIS, за да се изпълни приложението. При инсталиране на ASP.NET приложения на Windows Server 2003, те се изпълняват от IIS 6.0. При по-стари версии на Windows, се използва IIS 5.0 или 5.1.

IIS 6.0 позволява два режима на изолация на приложенията:

• 
  изолация на работния процес (по подразбиране)
  
• 
  IIS 5.0 режим на изолация
  

IIS 6.0 и изолация на работния процес

Когато ASP.NET приложенията работят в режим на изолация на работния процес, те работят в процеса W3wp.exe. В този случай моделът на проце­сите, който е вграден в ASP.NET е изключен и се използва архитек­турата на изолация на работния процес от IIS 6.0. С този режим на изолация може да се изолира всичко (от дадено уеб приложение до множество сайтове) в собствен процес на WWW услугата (WWW Publishing Service), като по този начин дадено проблемно приложение не може да повлияе негативно на останалите.

Процесите, изпълняващи отделните приложения, са напълно разделени от основната WWW услуга – Inetinfo.exe. ISAPI приложенията (Internet Server Applications) също работят напълно отделно от WWW услугата, което предпазва всички сайтове на сървъра от грешки в изпълнението им. Ако възникне грешка в ISAPI приложение, само процесът, който съдържа проб­лемното ISAPI, е засегнат.

Работният процес може да бъде конфигуриран да използва определен процесор, което позволява по-голям контрол върху разпределението на системните ресурси. Като допълнение уеб приложе­нията се стартират в контекста на Network Server акаунта, който има по-малки привилегии за достъп от LocalSystem. Това води до повиша­ване на сигурността.

IIS 5.0 и режим на изолация

Ако се използва изолационният модел на IIS 5.0, ASP.NET се изпълнява в собствения модел на процесите (Aspnet_wp.exe) и използва собствените конфигурационни настройки. Зададеният изолационен модел е на ниво сървър и важи за всички приложения, използващи IIS.

IIS 5.0 режим на изолация трябва да се използва от приложения, които влизат в конфликт с режима на изолация на работния процес. Следните характеристики създават посочения конфликт:

• 
  Зависимост от Inetinfo.exe. Ако приложението изисква да се стартира в контекста на процеса Inetinfo.exe, тогава трябва се използва IIS 5.0 режим на изолация.
  
• 
  Изисква се използването на Read Raw Data Filters. Тяхното изпол­зване изисква IIS 5.0 режим на изолация.
  
• 
  Изисква Dllhost.exe. Приложенията, които трябва да се изпълняват в обкръжението на Dllhost.exe могат да бъдат изпълнени само в IIS 5.0 режим на изолация.
  

Ако е необходимо изпълнението на приложение което, не изпълнява изискванията за изпълнение в режим на изолация на работния процес, трябва да се премине към IIS 5.0 режим на изолация. В такъв случай не могат да се използват предимствата на изолацията на работния процес от IIS 6.0.

Конфигуриране на изолационния режим

Изолационният режим може да се конфигурира от административната конзола на IIS по следния начин (примерът е с Windows 2003 Server):

1. 
   Стартираме административната конзола на IIS от Control Panel -> Administrative Tools -> Internet Information Services (IIS) Manager:
   

2. 
   Избираме с десен бутон на мишката Web Sites и от контекстното меню – Properties.
   
3. 
   Появява се диалоговия прозорец “Web Sites Properties”. Избираме таба Services:
   

4. 
   В зависимост дали е избрана опцията (Run WWW service in IIS 5.0 isolation mode) се определя изолационния режим, в който се изпълнява Internet Information Server.
   
5. 
   След промяна на изолационния режим е необходимо рестартиране на IIS, за да влязат в сила направените промени.
   

Конфигурация на ASP.NET приложенията

Конфигурацията за ASP.NET приложенията се съхраняват в
елемента от файла machine.config. Ако се използва IIS 6.0 в режим на изолация на работния процес, се използват само следните настройки:

• 
  maxWorkerThreads – максимален брой нишки на процесор, които изпълняват ASP.NET приложенията
  
• 
  maxIoThreads – максимален брой нишки на процесор, които изпълняват входно-изходни зачачи
  
• 
  responseDeadlockInterval – задава максимално време, за което всяка заявка трябва да приключи (процесът се рестартира, ако някоя заявка се забави повече)
  

Всички останали настройки се игнорират. В някои случаи другите настройки са без значение за IIS 6.0, но в други следва техните екви­валенти в IIS 6.0 метабазата да бъдат указани. За повече информация виж “Mapping ASP.NET Process Model Settings to IIS 6.0 Application Pool Settings” в MSDN Library.

Промяна на регистрите на Windows

.NET приложенията би следвало да използват в по-малка степен регис­трите на Windows отколкото Win32 приложенията. Например асемблитата не изискват съществуването на ключове в регистрите за разлика от COM базираните обекти в миналото. В някои случаи приложенията все още разчитат на регистрите, например когато:

• 
  Приложенията включват компоненти, които не са изградени с .NET Framework като COM, COM+ или услуги под Windows (Windows services).
  
• 
  Асемблитата трябва да комуникират с COM базирани компоненти или предос­тавят услуги, достъпни през COM. В такъв случай записите в регист­рите трябва да се направят по време на инсталационния процес.
  
• 
  Необходимо е добавянето на записи относно лицензиранe или версионизиране.
  

Споделени инсталационни компоненти (Merge Modules)

Споделените инсталационни компоненти са преизползваеми модули за Windows Installer (обикновено са файлове с разширение .msm). Те не могат да се инсталират директно, а трябва да се включат в инсталацион­ния пакет на приложението, което ги използва. Както динамично свърза­ните библиотеки позволяват преизползването на код и ресурси от няколко приложения, така споделените инсталационни компоненти позволяват споделяне на инсталационен код между MSI пакетите. По този начин се осигуряват едни и същи действия за коректно инсталиране на определен компонент с всички приложения, които го използват. Споделените инста­лационни компоненти са подходящи за инсталирани на компоненти на други производители, използвани в нашето приложение (например MSDE – Microsoft SQL Server 2000 Desktop Engine).

Споделените инсталационни компоненти могат да бъдат използвани само в инсталационни пакети на Windows Installer и по никакъв друг начин.

CAB файлове

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

Създаването на CAB файлове предоставя следните предимства:

• 
  Позволяват сваляне от Интернет и контролите с управляван код, които се съдържат в тях, могат да се изпълняват при поискване (on demand).
  
• 
  Позволяват няколко нива на компресия, което намалява времето за изтеглянето им по мрежата.
  
• 
  Позволяват използването на Microsoft Authenticode® технологията за подписване на CAB файловете, така че може да се покаже на потребителите кой е производителят.
  
• 
  Съдържат контроли, които лесно могат да бъдат подменени с по-нова версия, чрез създаване на нов CAB файл и поставянето му на уеб сървър. CAB файловете поддържат версионизиране, като по този начин се осигурява използването на най-новата версия от потреби­телите.
  

Локализиране

CLR предоставя поддръжка за извличане на културно-зависими ресурси, които са пакетирани и инсталирани в сателитни асемблита. Сателитните асемблита съдържат само ресурси, които се използват от приложението (.resx, .gif, .jpeg и др.). Те не съдържат изпълним код.

Когато се използва моделът със сателитните асемблита за локализиране на приложенията, структурата е следната: съществува главно асембли съдържащо културата, която се използва по подразбиране и множество сателитни асемблита. В главното асембли се пакетират културно-незави­симите ресурси и се създава сателитно асембли за всяка култура, която ще се поддържа. Понеже сателитните асемблита не са част от главното асембли тяхната замяна или ъпгрейд са много лесни и се осъществяват без да се променя главното асембли на приложението.

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

При създаване на .NET приложения, поддържащи множество култури, процесът по разпространение може да се изпълни по няколко начина:

Подход 1: Language packs

Най-лесният подход при разпространение на локализирани приложения е създаване на основен инсталационен пакет и набор от инсталационни пакети за поддържаните култури (познати като езикови пакети - language packs). По този начин клиентите инсталират основния пакет и след това необходимите езикови пакети.

Подход 2: Използване на споделен инсталационен компонент

• 
  Пакетиране на основните, културно-независими асемблита в споде­лен инсталационен компонент (Merge module) чрез Visual Studio .NET setup and deployment project.
  
• 
  Създаване на инсталационен проект, който съдържа локализираните ресурси за всички поддържани култури.
  
• 
  Създаване на MSI пакет за всяка култура. Това позволява локализи­ране и на инсталационния процес, а не само на приложението.
  
• 
  Създаване на базов инсталационен пакет за основната култура, която ще се поддържа и след това се създава трансформация (transform) за всяка допълнителна култура, която ще се поддържа.
  
• 
  Добавяне на компилираните асемблита от проекта (project output), който съдържа локализираните ресурси във всеки проект на Windows Installer. Важно е включването на всички локализирани ресурси. След това се използва филтър (ExcludeFilter) за изключване всички (освен една) култури от инсталацията.
  

Подход 3: Инсталиране на всички ресурси

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

Debug Symbols

Когато се създава приложение с помощта на Visual Studio .NET 2003 се създават два вида конфигурации по подразбиране – Release и Debug. Едно от основните различия между тях е начинът, по който се управляват дебъг символите. С Debug конфигурацията се създава файл с дебъг символите за програмата (.pdb – program database), докато при Release такъв файл не се създава по подразбиране.

Файлът с дебъг символите е необходим на CLR, за да свърже компили­рания MSIL код със сорс кода. Това позволява на дебъг-инструментите да показват информация като имена на променливи; на JIT компилатора да създаде проследяваща информация, чрез която да се свърже машинно-зависимия код (native code) обратно до MSIL. Проследяващата информа­ция и символните файлове са необходими за ефективно дебъгване на управлявания код.

Включването на символните файлове в инсталационните пакети помага да се локализират грешките (JIT компилаторът показва дори номера на реда в кода, където е възникнала грешката), затова е препоръчително да се включат в инсталационните пакети по време на тестовете, а при приключ­ване на тестването да се премахнат.

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

Конфигуриране генерирането на дебъг информация:

Генерирането на символните файлове се определя с /debug ключа на компилатора от командния ред (csc.exe) или във Visual Studio .NET от прозореца с характеристиките на проекта (от страницата Build от групата Configuration Properties):

Каталог: dotnetcourse -> Beta1
Beta1 -> Изграждане на графичен потребителски интерфейс с Windows Forms
Beta1 -> Управление на паметта и ресурсите
Beta1 -> Уеб услуги с asp. Net
dotnetcourse -> Въпрос: Кога е нужно да слагам в класовете си свойства, и кога мога да слагам публични полета? Не е ли вторият вариант по-удобен, особено когато едно поле не се валидира по никакъв начин? Отговор
Beta1 -> Отдалечени извиквания с. Net remoting
Beta1 -> Сериализация на данни

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

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