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

No-Touch Deployment (.NET Zero Deployment)

Изключителното предимство на тази технология е, че се комбинира богатият потребителски интерфейс на Windows базираните приложения с лесната инсталация и поддръжка, характерна за уеб приложенията. Понеже асембли­тата се свалят само когато са необходими, се минимизира времето за начално зареждане на приложението. Всичко това се случва автоматично – когато клас от главното асембли създава инстанция на клас от асембли, което се намира в същата папка на уеб сървъра, CLR го сваля.

При всяко стартиране на приложението (и първоначално използване на асембли) CLR проверява дали асемблитата на уеб сървъра имат по-нови версии от тези в кеша и при необходимост сваля по-новите версии. По този начин инсталирането на по-нови версии е изключително лесно, като всичко, което е необходимо да се направи, е да се заменят асемблитата на уеб сървъра с по-нови версии.

Кога да ползваме No-Touch Deployment?

• 
  При необходимост да се контролира строго мрежовият трафик и да се прогнозира неговото използване. Тъй като асемблитата се свалят само когато са необходими, съществува потенциална възможност за пикови натоварвания на мрежовите ресурси, когато много потреби­тели изискват едновременно някои асемблита.
  
• 
  При необходимост за използване на приложението offline. Съхраня­ване на асемблитата в кеша позволява тяхното стартиране дори когато няма връзка с уеб сървъра, но в такъв случай ще се изпол­зват само вече кешираните асемблита. При използване на функцио­налност от асемблита, които не са свалени, ще възникне грешка, тъй като CLR не може да ги изтегли.
  
• 
  Когато се изискват допълнителни действия по време на инстала­ционния процес като инсталиране на COM обект или драйвер за устройство.
  
• 
  Когато са необходими високи права. По подразбиране приложе­нията, разпространявани с no-touch deployment, се стартират в ограничен контекст на сигурността. Не е подходящо използването на тази технология, когато не е практично да се променя политиката по сигурността (security policy).
  
• 
  Когато е необходимо поставянето на асембли в Global Assembly Cache.
  

Дали приложението работи в online или offline режим се определя от режима на Internet Explorer. Дори и компю­търът да има връзка с даден уеб сървър, ако Internet Explorer е в offline режим, тогава и CLR ще работи в offline режим.

Възможно е използването на устройство в локалната мрежа (network share), вместо уеб сървър. По този начин потребителите се свързват и директно стартират приложението оттам. Чрез този подход асемблитата не се кешират, а се зареждат директно в паметта. Основен недостатък е, че е невъзможно offline използването при срив на мрежовото устройство.

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

Приложения, състоящи се от множество асемблита

Приложения, които се състоят от едно асембли са най-лесни за разпрост­ранение чрез .NET Zero Deployment. Често, обаче, напълно функционал­ните приложения използват множество асемблита и множество ресурси. Разпространението на такива приложения с .NET Zero Deployment е възможно, но изисква допълнителни усилия от разработчиците, за да се осигури оптимизация.

С цел извикване на асемблита само когато са необходими може да се използва класът Assembly от пространството System.Reflection. Assembly. В този клас има метод LoadFrom(string path, …), чийто параметър path приема както URL, така и пълно име на локален файл. Когато е подаден URL като параметър, CLR проверява дали изисква­ното асембли не съществува вече в download кеша. Предимството на тази техника е, че асемблито се сваля от уеб сървъра, само когато е извикано от приложението (on demand), въпреки, че може да доведе до забавяне на приложението докато асемблито се свали на локалната машина.

Решение на проблема с ограниченията на .NET Zero Deployment техно­логията е използване на комбиниран метод на инсталация – компонен­тите, за които трябва да се предоставят често нови версии, се поставят на уеб сървър, а политиката на сигурността и останалите компоненти се инсталират чрез Windows Installer технологията.

Този подход набра популярност и Майкрософт решиха да го доразвият във .NET Framework 2.0 и нарекоха технологията ClickOnce. На етап от Visual Studio .NET 2005 и .NET Framework 2.0 основните възможности, които са добавени, са следните:

• 
  Уведомяване на клиентите при публикуване на нова версия.
  
• 
  Избор на потребителите дали да инсталират новата версия - разра­бот­чиците могат да посочат най-старата версия, която е допустимо да бъде стартирана.
  
• 
  Инсталиране/деинсталиране – създаване/изтриване на препратки (shortcuts) в подходящите папки.
  
• 
  Генериране на подходящи уеб страници за уведомяване на потре­бителя.
  
• 
  Опция за стартиране в offline режим – улеснено е в сравнение с .NET Framework 1.х.
  

Windows Installer

Следващата стратегия за разпрострения на приложенията е чрез инстала­ционни пакети на Windows Installer (.msi файлове). Тази стратегия пред­лага най-много възможности сред изброените и чрез нея могат да се инсталират всички видове .NET приложения заедно със споделените инсталационни компоненти (merge modules) и CAB файлове.

Предимства на Windows Installer

Windows Installer предлага множество улеснения за потребителите, адми­нистраторите и разработчиците. Основните от тях са:

• 
  Лесен за използване потребителски интерфейс, който може да се настройва от разработчиците (customizable UI).
  
• 
  Интеграция с инструмента Add/Remove Programs от Control Panel за следните действия:
  
  • 
    Инсталиране.
    
  • 
    Деинсталиране.
    
  • 
    Добавяне или премахване на функционалност (features) от приложенията.
    
  • 
    Поправяне на инсталираното приложение като се запазват напра­вените промени и се възстановяват повредените файлове.
    
• 
  Изпълнение в тих режим (silent mode) – без намесата на потреби­теля.
  
• 
  Възстановяване на системата до състоянието преди започване на инсталацията в случай на:
  
  • 
    Възникване на грешка.
    
  • 
    Прекъсване от потребителя.
    
• 
  Проверяване за наличието на определен софтуер и хардуер преди започване на инсталацията.
  
• 
  Създаване на подходящи препратки (shortcuts).
  
• 
  Управление на местоположението на файловете и папките.
  
• 
  Управление на регистрите на Windows (Windows registry).
  
• 
  Инсталиране на COM базирани компоненти.
  
• 
  Инсталиране на асемблита в Global Assembly Cache.
  
• 
  Изпълнение на допълнителни действия след инсталацията (custom actions).
  
• 
  Управление на информацията за версиите, като по този начин се осигурява инсталиране на ъпгрейдите (upgrades) и кръпките (patches) в правилен ред.
  

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

Задача	Решение чрез MSI пакет
Споделени асемблита – поставяне на асемблита в GAC	Windows Installer предоставя лесен начин за инсталиране на споделени асемблита в Global Assembly Cache.
Инсталиране на COM базирани компоненти	Както обяснихме в точка COM базирани обекти, COM обектите трябва да се регистрират преди да се използват. Windows Installer предоставя надежден механизъм за инсталиране и регистриране на COM обекти. При нужда може да се използва и инстру­мента RegSvr32.exe за ръчно регистриране на COM обектите.
Настройки на IIS	В точка Настройки на Internet Information Server (IIS) обяснихме основните настройки, които трябва да бъдат направени, за да се стартират уеб прило­жения. Windows Installer позволява задаването на тези настройки по време на създаване на инстала­ционния пакет.
Ресурси на приложението	Приложенията изискват различни ресурси като опашки от съобщения (message queues), логове на събитията (event logs), индикатори за производи­телността (performance counters) и бази данни (databases) (виж Инсталационни компоненти), сате­литни асемблита за локализиране на приложението (виж. Локализиране). Windows Installer поддържа изпълнението на допълнителни действия (custom actions) преди приключване на инсталационния процес, чрез които могат да се изпълнят почти всички необходими действия.

Windows Installer за инсталиране на многослойни приложения

При комплексни системи, изградени от няколко слоя, трябва да се изпол­зва отделен инсталационен пакет за всеки отделен физически слой (всяка отделна машина). Това е подходящо при повечето сценарии, защото е изключително трудно (в някои случаи дори невъзможно) да се стартира един инсталационен процес на даден физически слой и да се инсталират компоненти на други физически слоеве като част от него. Например ако се стартира инсталационен пакет за уеб приложение, е трудно да се инсталират компонентите, които съдържат бизнес логиката, на отделен компютър. В някои случаи за всеки отделен физически слой може да бъде избрана различна инсталационна стратегия. Например слоят, който съдържа уеб-базираният потребителски интерфейс може да бъде разпро­странен като колекция от файлове след компилацията, докато слоят с бизнес логиката и сървърът за базата данни могат да бъдат поставени в MSI пакет.

Съображения за сигурността

Един от проблемите, които засягат разпространението на Windows бази­рани приложения чрез MSI пакети е дали потребителят, който е стартирал инсталационния процес, има необходимите права, за да проведе и при­ключи инсталацията. Тези права зависят от действията, които се извър­шват по време на инсталационния процес и платформата, върху която се осъществяват. Например не се изискват специални права, за да се инсталират приложения върху Windows 95, Windows 98, Windows Me, докато в Windows NT/2000/XP/2003 само създаването на поддиректория на системната папка Program Files изисква потребителят да е в група със специални права (като Administrators или Power Users).

Начин да се осигурим, че инсталацията няма да се провали заради недо­статъчни права на активния потребител, е разпространение на инстала­ционния пакет чрез MS SMS или Active Directory Group Policy.

Разпространение на пакети на Windows Installer

Съществуват различни начини за разпространение на MSI пакети:

• 
  Active Directory Group Policy.
  
• 
  MS System Management Server (SMS).
  
• 
  Други начини – поставяне на файлов сървър, на уеб сървър или разпространение на носител (CD/DVD).
  

Нека разгледаме всеки един от тях.

Групови политики на активните директории (Active Directory Group Policy)

При работа в големи организации работните станции се организират в домейни, управлявани от т. нар. активна директория (Active Directory). Тя е част от сървърните Windows платформи (Windows 2000 Server, Windows 2003 Server и т. н.) и се използва за централизирано управление на Windows базирани корпоративни инфраструктури.

Активната директория позволява разпространението на приложение до потребителите или машините автоматично, чрез използва­нето на групо­вите политики (Group Policy). Груповите политики могат да се задават на ниво домейн, организационна единица, потребител или компютър. Това зависи от структурата на дадената организация. Чрез груповите политики може да се осигури автоматично инсталиране на приложението, когато даден потребител се включи в системата (или даден компютър се стар­тира).

Груповите политики позволяват разпространение на приложения по два начина:

• 
  Назначение (assign) – администраторът може да назначи дадено приложение за потребители или машини.
  
  • 
    За потребители – приложението се инсталира, когато даденият потребител се включи в системата. Когато потребителят стартира някоя програма за първи път, тогава инсталацията се финали­зира.
    
  • 
    За машини – когато машината се стартира, приложе­нието се инсталира и то е свободно за използване от всички потребители на тази машина. Инсталацията се финализира, когато потребите­лят стартира някоя програма.
    
• 
  Публикуване (publishing) – приложението може да се публикува за определени потребители. Когато те се включат публикуваната про­грама се появява в Add/Remove Programs и може да бъде инстали­рана от там. Като алтернатива може да се посочи приложението да се инсталира при стартиране на файл, чийто тип е асоцииран с него.
  

Разпространение на MSI пакет чрез групова политика на активната директория – пример

За да настроим инсталационен пакет за инсталиране чрез груповата политика на активната директория (Active Directory Group Policy), можем да изпълним следните стъпки (примерът е с Windows 2003 Server):

1. 
   Създаваме директория, която ще съдържа MSI пакета на файлов сървър. Настройваме директория за съвместно ползване (shared directory) и задаваме необходимите права.
   
2. 
   Стартираме конзолата "Active Directory Users and Computers".
   
3. 
   От структурата вляво избираме контейнера, който съдържа компют­рите, за които ще назначаваме инсталация на приложение. Щрак­ваме с десния бутон на мишката върху него и избираме Properties и после Group Policy таба.
   
4. 
   Създаваме нова групова политика (Group Policy Object), чрез бутона [Add] и задаваме подходящо име. Например “MSI Install Test”:
   

5. 
   Уверяваме се, че новата група е избрана и натискаме бутона [Edit]. Ще се отвори конзолата Group Policy Object Editor.
   
6. 
   От дървото вляво отваряме Computer Configuration, разпъваме пап­ката Software Settings и избираме иконата Software Installation. От нейното контекстно меню избираме New… | Package:
   

7. 
   Отваря се диалог, чрез който трябва да изберем .msi файла за този пакет. Намираме споделената папка на файловия сървър, която създадохме в стъпка 1. Избираме файла и потвърждаваме с бутона [Open]. Ако файлът се намира на локалния диск, не трябва да използваме локалния път (примерно c:\PathToMSI), защото клиен­тите няма да имат достъп до пакета. Вместо това трябва да изпол­зваме UNC път – \\име-на-сървъра\име-на-папката\файл.msi.
   
8. 
   От следващия диалогов прозорец избираме [Assigned] и потвържда­ваме с [OK]:
   

Ако изберем вместо това [Advanced], ще се отвори нов прозорец, в който можем да правим допълнителни настройки за разпростране­нието на пакета. Това може да стане и по-късно чрез избиране на Properties от контекстното меню на създадения пакет.

9. 
   Виждаме новосъздадения пакет в конзолата Group Policy Object Editor. В нашия случай той ще бъде инсталиран при следващото влизане на потреби­телите в системата или при стартиране на компютрите, които са част от домейна.
   

MS System Management Server (SMS)

System Management Server v2.0 служи за лесно централизирано управ­ление на инсталации на софтуерни пакети в корпоративна мрежа Основ­ните предимства на SMS са:

• 
  Разпространение на приложения на множество клиентски платфор­ми. Всички версии на Windows се поддържат от SMS.
  
• 
  Контрол над натоварването на мрежата. SMS позволява наблюдение на мрежовия канал и неговото натоварване като позволява настрой­ване и избягва допълнителното натоварване в неподходящо време от денонощието.
  
• 
  Работа с определени потребители и машини. Приложенията може да се разпространяват на база потребителско име, име на група, име на компютър, име на домейн и мрежов адрес.
  
• 
  Използване на график за разпространение на софтуер. Разпрост­ранението се извършва по предварително указан график. Това е полезно за избягване на натоварването по определено време на денонощието.
  
• 
  Състояние на разпространението. SMS показва състоянието на инстала­цията и позволява навременно реагиране в случай на грешки.
  
• 
  Краен резултат на разпространението. Ако приложението е било успешно инсталирано на даден клиент, това не означава, че целият процес е бил успешен. SMS предоставя детайлна информация за крайния резултат.
  

SMS има свой механизъм за разпространение на приложенията и не изисква задължителното използване на пакети на Windows Installer, но поддържа MSI пакети.

Други методи

Съществуват и няколко други метода за разпространение на MSI пакети:

Метод	Описание	Предимства/Недостатъци
Уеб/FTP сървър	Пакетите са поставени на сървър от локалната мрежа или в Интернет и връзка към тях е изпратена на потребителите.	Добър начин за предоставяне на приложе­ние на широка аудитория. Пакетите могат да бъдат архивирани (на­пример в .ZIP архив), за да се избегне директно стартиране. Няма контрол върху свалянето на пакетите. Изискват се административни права за ус­пешна инсталация.
Мрежов сървър	Пакетите са поставени на сървър и връзка към тях е изпратена на потребителите.	Добър начин за разпространение в дадена организация. Пакетите могат да бъдат архивирани (на­пример в .ZIP архив), за да се избегне директно стартиране. Няма контрол върху свалянето на пакетите. Изискват се административни права за ус­пешна инсталация.
E-mail	Пакетите се изпращат чрез електронната поща	Лесни са за намиране. Не могат да се стартират директно, заради блокирането им от клиентите за електрон­на поща. Могат да бъдат филтрирани от системи за защита от спам и вируси. Може да доведе до значително натовар­ване на сървърите. Изискват се административни права за ус­пешна инсталация.
CD/DVD	Пакетите са записани на оптичен носител.	Лесно преносими. Подходящи, където мрежовият канал не е достатъчно широк или пакетите са много обемни. Изискват се административни права за ус­пешна инсталация.

Инструменти за създаване на MSI пакети

Visual Studio .NET 2003 поддържа създаването на инсталационни проекти, въпреки че не използва пълните възможности на технологията Windows Installer. Затова ще посочим най-често използваните инструменти за работа с MSI пакети. Основно може да разделим инструментите на две групи:

1. 
   Произведени от Майкрософт:
   

• 
  Visual Studio .NET 2003 – поддържа създаването на основни инсталационни пакети и предлага сравнително добър интерфейс за изграждане на инсталационния процес. Подходящ е за средни по сложност приложения.
  
• 
  Orca – съдържа се в Platform SDK. Предлага среда за редактиране на файлове на Windows Installer (.msp, .msi, .msm). Изключи­телно мощен, но сложен – подходящ за експерти в технологията Windows Installer.
  
• 
  Windows Installer XML (WiX) – това е проект по инициатива на Майкрософт и по M Shared Source Licensing (виж http://www.microsoft.com/resources/sharedsource/licensing/WiX.mspx и http://sourceforge.net/projects/wix/). Позволява описанието на MSI пакетите да се използва XML сорс код, който се компилира до .msi файл. Подходящ за напреднали разработчици.
  

2. 
   От други производители:
   

• 
  InstallShield – продукт на Macrovision (бившата InstallShield). Изключително интуитивен и лесен за използване интерфейс. Работата е улеснена от наличието на съветници (wizards). Инте­грира се отлично във Visual Studio .NET 2003. Документацията е много подробна и за най-често използваните задачи са дадени примери. Предоставя свой собствен скриптов език (InstallScript), който позволява контролиране на инсталационния процес във всичките му аспекти. Официалният уеб сайт на InstallShield е http://www.installshield.com/products/installshield/.
  
• 
  Wise for Windows Installer – продукт на Wise, който се интегрира с Visual Studio .NET 2003. Мощен продукт и лесен за употреба. Също предоставя свой скриптов език за контролиране на инстала­ционния процес. Официалният уеб сайт на Wise for Windows Installer е http://www.wise.com/wfwi.asp.
  

Колекция от файлове след компилация

За много уеб приложения и някои опростени Windows приложения е по-подходящо разпространението чрез просто копиране на файлове на сървъра, вместо изграждането на сложни MSI пакети. Под колекция от файлове имаме предвид всички файлове, които се използват от прило­жението – .apsx, .dll, .exe, .config, графични файлове и други ресурси.

Предимствата на тази инсталационна стратегия са:

• 
  Леснота за инсталиране – файловете се инсталират на машината чрез просто копиране.
  
• 
  Леснота за ъпгрейд – новите файлове се копират върху старите.
  

За разлика от Windows базираните приложения, уеб приложенията се инсталират от администратор или опитен IT специалист. В много случаи такива приложения не се инсталират, деинсталират и поправят чрез Add/Remove Programs от Control Panel. Възстановяване предишното състояние на машината при грешка също не е необходимо условие – по-лесно е за администратора да промени настройките на IIS или да отстрани дребни проблеми вместо да рестартира целия инсталационен процес.

Въпреки, че тази стратегия работи добре с по-прости приложения, тя не е подходяща при следните ситуации:

• 
  промяна в Windows Registry
  
• 
  добавяне, изтриване или промяна на Windows услуги
  
• 
  промяна по политиките на сигурността (security policy)
  
• 
  добавяне, изтриване или промяна на COM базирани обекти
  
• 
  работа с Global Assembly Cache
  

При работа с по-сложни приложения е препоръчително използването на Windows Installer.

Начини на разпространение

Самото разпространение на файловете може да се извърши по следните начини:

• 
  Чрез Microsoft Application Center – изключително подходящо при т. нар. уеб ферми (Web farms). Те представляват клъстер от няколко машини, които предоставят уеб услуга или уеб приложение. При инсталиране на уеб приложение върху уеб ферма е необходимо всяка една от машините да има едни и същи файлове, инсталирани компоненти, настройки на IIS и др. Използването на Microsoft Application Center осигурява съдържанието на машините в уеб фер­мата да бъде еднакво. Microsoft Application Center не е подходящ за разпространение на MSI пакети, Windows базирани приложения, Windows услуги и бази данни.
  
• 
  Чрез Copy Project командата от Visual Studio .NET 2003 (само за уеб приложения). Създава виртуална директория на посочения сървър и копира файловете в нея:
  

Има следните опции за копиране:

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

• 
  Директно копиране на файлове – подходящо е само, ако не трябва да се променят регистрите на Windows (Windows registry) или да се изпълняват допълнителни задачи (като настройки и рестартиране на IIS, промяна на настройките за сигурността и т.н.).
  

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

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

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