Проблемы развертывания ASP.NET сайтов

Изначальная разводка MS была в том, что ASP.NET-сайты должны разворачиваться путем XCOPY - Deploy ASP.NET applications using Xcopy - те просто копированием каталога c сайтом. С девелоперского кампутера на хостинг, с одного хостинга на другой.

Думаю, пришло время разоблачить и это мошенничество Микрософта - и самого богатого человека планеты. Говорят что сейчас какой-то мексикос потеснил чуток Билла на второе место, но сути мошенничества Билла (заведомое введения потребителей в заблуждение о качественных характеристиках технологии ASP.NET по корыстным мотивам) - это не меняет.

Итак, перечислим некоторые причины утяжеления технологии ASP.NET, делающие невозможным простое развертывание ASP.NET сайта копированием в целевую среду, как это делают например PHP-программисты.

• 1. Первой супер-привязкой к целевой среде развертывания сайта является использование MS SQL-сервера. MS SQL Server - весьма специфическая игрушка, диктующая определенную архитектуру приложения в целом. Я обязательно посвящу этому отдельный топик на своем блоге, но пока скажу, что архитектура ASP.NET сайтов часто строится на возможностях SQL-сборок - например почитайте про мою OpenSource SQL-CLR-Assembly - SQL-Client_for_remote_XML-WebService - клиент meteonova.ru. Другие привязки к SQL-серверу - по SQL-заданиям - Выполнение периодических задач в ASP.NET. Третий тип привязок - обработке XML (конец страницы Выгрузка базы в XML).

  Даже в рамках разных редакций того же MS SQL Server 2008 (Developer, Express, Compact, Web, Workgroup, Standard, Enterprise, Datacenter, Parallel Data Warehouse) возникает множество проблем, весь более ли менее реальный функционал - платный. Все этот функцинал есть в Developer-edition, но отсутствует в наиболее распространенной бесплатной Express Edition. Начиная от заданий SQL и кончая сплитингом - Cекционирование графики при SQL-хранении. Те вы отладили сайт в своей девелопесркой среде с заданиями, dbMail, сборками и сплитингом - а развернуть его надо на SHARED-хостинге GoDaddy или Паркинга - а сделать это НЕВОЗМОЖНО ! Вы тупо не можете передать свой сайт заказчику - вы его сделали в MS SQL Server Developer Edition, а заказчик оплатил Web Edition, или вообще хочет пользоваться Express.

  Есть несовместимость не только между редакциями одного и того же MS SQL 2008, но и между разными версиями MS SQL. Например я сделал сайт для железной дороги на SQL2005 Developer, а оказалось что там стоят только лицензионные SQL 2000. У которого даже SQL-синтаксис другой.

  Я сталкивался с подобными несовместимостями настолько часто, что просто не нашел иной возможности работать с клиентами, кроме создания своего собственного хостинга - //www.vb-net.com/ - иначе даже показать собственный созданный ASP.NET сайт просто не удается! Тем более сертифицированные MS публичные SHARED-хостинги даже для простейших студенческих проделок роботают свершенно неприемлимо.

  Еще хуже дело с переносимостью ASP.NET сайта обстоит, если вы вообще хотите в целевой среде использовать не MS SQL, а хотите развернуть сайт на другом SQL-сервере. Тут выплывут и привязки по типам данных, по процедурам, делающим рекурсивный обход с помощью CTE - и еще по тысяче причин. Поэтому выполнение вот таких задач Используем MySQL вместо MS SQL в проектах на ASP.NET, Используем PostgreSQL вместо MS SQL в проектах на .NET и ASP.NET - требует соблюдения ТЫСЯЧ позиций по выполнению совместимости.

  Когда у меня будет живой проект по миграции ASP.NET сайта с одной СУБД на другую - я обязательно опубликую более или менее веский список - как избавится от зависимости от MS SQL-сервера.

  
  
• 2. На целевом кампутере должна быть установлена среда NET - что например встречается не часто (почему я и не удаляю VB6 с кампутера). Я не раз встречал на фрилансерских форумах фразу - присутствие NET на целевом кампутере недопустимо - сайт может разворачиватся в разных организациях.

  И я по прежнему пишу на VB6 все инсталяторы для расписывания библиотек по диску, загрузки драйверов, прописывания ключей рееста и прочей подстройке целевой среды сайта.

  
  
• 3. Естественно версия NET должна присутствовать нужная. Например сайт сделан с использованием возможностей WSE 2.0 - а он идет исключительно на NET 1.1 - кто знает на целевом кампутере для показа - что вообще такое NET 1.1? Ну и вообще версии NET отличаются больше чем принято считать. Например в NET 1.1 я помню как пользовался System.Collections.CollectionsBase. При переходе с NET 1.1 на NET 2.0 я с удивлением обнаружил что в NET 2.0 удалена эта коллекция и еще две тысячи методов и свойств.
  
  
• 4. На целевом кампутере должна ТОЧНО совпадать версия сборок в рамках той же версии NET - например есть бейсик 8.0 идущий с офисом - если ты откомпилил сайт на нем, со сборкой бейсика, который идет в обычной комплекте NET - сайт уже не пойдет. Вот пример такой проблемы - версия сборки бейсика РАЗНАЯ в NET Framework 2.0. Вот еще скрины с анализом этой же проблемы - когда cгруженный с сайта MS NET 2.0 после каких-то обновлений получал ИНУЮ нумерацию сборок - естественно откомпилированный сайт в целевой среде уже не пойдет.
  
  
• 5. Сам по себе NET-это не монолит. Типо ты поставил NET 2.0 - и он есть у тебя. Он состоит из многих-многих отдельных пакетов. Например пакет SqlManagement. Это совершенно автономный пакет NET - причем еще и зависимый от версии MS SQL. Пока ты не знаешь что такое обзор доступных SQL-серверов - твое счастье. Как только твой сайт будет делать обзор SQL-серверов (ХОТЯ БЫ!) - не говоря уже о более серьезных вещах - ты поймешь что означает фраза - весь NET не устанавливается за раз одним пакетом.
  
  
• 6. Для обеспечения переносимости сайта - в коде сайта надо стремится минимизировать использование доменных имен - все адреса должны быть относительные.
  
  
• 7. Если ASP.NET-сайт использует внешние Web-Сервисы (тем более по SSL) - то доступ к ним должен быть разрешен из целевой среды запуска сайта. Те сервисы надо открывать для новых айпишников минимум.
  
  
• 8. На переносимом сайте не должно быть платных или условно бесплатных программ типа DevExpress или CrystalReport - которые просто не дадут твоему сайту отработать. Или платных CMS, например Digimaker. Много крови у меня выпил и Crystal report при переносе его на другой хостинг - Изготовление отчетов в ASP.NET2
  
  
• 9. На целевой среде должны присутствовать все библиотеки сайта. Например некоторые мои сайты имеют 72 библиотеки. Которые пишутся отдельными людьми, компилируются в отдельных средах со своими ссылками. При развертывании сайтов надо зафиксировать релиз всех библиотек, все ссылки. Это нетривиальная процедура, для которой в Visual Studio не предусмотрено никаких инструментов. Как выносить релизы таких сайтов я описал в самом низу этой странички Настройка IIS и развертывание сайта.
  
  
• 10. Многие библиотеки сайта в принципе невозможно запустить из директории BIN проекта. Например listener, которые подключаются в разделе корнфигурации system.diagnostic. Их надо ставить в GAC-кампутера. Тут тоже вдруг как всегда оказывается. что на целевом кампутере нету утилиты GacUtil.
  
  
• 11. Почти не существует сайтов, которые бы не высылали какие-то почтовые уведомления, сообщения об активации и прочие штучки по почте. При запуске сайта в иной среде - будет совсем другой почтовик, который может например не принимать вложения или вообще работать в другой кодировке. Но мир почты - это отдельным мир вообще. Даже связь ASP.NET сайтов с миром почты может быть организована по разному, например через SQL-сервер. Зачастую этот компонент вызывается уже изнутри сборки - как например вот в этом моем сайте Вариации на тему Notification-сервера.

  В последнее время, впрочем я нашел такой выход - работать с почтовыми серверами из ASP.NET только через посредника - ASSP. Это просто замечательная прога и в этой прослойке можно решить все проблемы связи почтовика и ASP.NET-сайта. Отдельно я эту технологию у себя в блоге не описывал, но многократно упоминал об этой технологии, например здесь ExchangeLogAnalyzer - OpenSource парсер журнала MS Exchange Server

  
  
• 12. На целевом кампутере для работы сайт должен быть добавлен в траст-зону для локального кампутере (если это сервер с установленной усиленной безопасностью) - это кажется мелочью, но например в учебном институте это было категорически запрещено доменной политикой и сайт при демонстрации не открылся.
  
  
• 13. На целевом кампутере должен быть IIS (что сложно для обычных самых убогих систем). А полноценный Win-сервер может быть не везде - он стоит не $20, а $4000.
  
  
• 14. IIS должен быть весьма тщательно сконфигурирован, в части запуска ASP.NET-приложений. Например среда 32/64. Если сайт сделан на децком кампутере, а показать его хочешь на взрослом, а IIS там не настроен в режим WOW - тогда ничего не получится. На том же IIS могут быть и другие сайты, которые не могут работать в этом режиме WOW.
  
  
• 15. Почти всегда требуется довольно тщательная настройка IIS. Там редко что стоит такое, что годится применить по умолчанию. Ну сейчас чрезвычайно трудно найти сайт например без прокрутки роликов (Мультимедиа на Web-страничках). А для этого уже надо добавлять тип .FLV в IIS - как минимум.
  
  
• 16. Сайты с виртуальными поддиректориями, тоже не получится запустить в иной среде без конфигурирования IIS.
  
  
• 17. Сайты многодоменной архитектуры (те портальной схемы) вообще нельзя показать на другом кампутере без перенастройки DNS. Чтобы показать сайт портальной схемы - придется повозится с DNS той локалки, где ты будешь это показывать и с настройками IIS. Эту тему я поднимал в топике - Рефакторинг отдельного сайта к Web-порталу.
  
  
• 18. Сейчас очень мало сайтов совсем без учета SEO-реврайтеров делается. Эти реврайтеры, например IIRF нехилой инсталляции требуют, и там конкретно надо вникнуть в расписывание безопасности по ISAPI-расширениям уже после инсталляции.
  
  
• 19. Иерархия конфигурационных файлов - мы ведь пишем в конфиге своего сайта не тысячу параметров? Полагаемся на иерархию умолчаний своего собственного кампутера. А кто сказал, что на целевом кампутере та же иерархия умолчаний?

  Предположим надо развернуть и продемонстрировать сайтик, на котором есть аплоад. И я принес с собой и ролик для аплоада. На моем кампутере все летало. А при показе стало. Оказывается предельный размер ролика для аплоада пишется в файлике maсhine.config, рамер которого на целевом кампутере не совпадает с девелоперским. Ни единого сообщения об ошибке не будет. Просто ASP.NET сайт не будет работать. Потому, что он опирается на огромную пирамиду СПЕЦИФИЧЕСКИХ конфигурационных файликов, запрятанных глубоко в недра системы.

  
  
• 20. Для переносимости в сайте не должно быть сертификатов, они не переносятся с кампа на камп легко - на практике сайты без сертификатов бывают, но редко. Иногда сертификаты напрямую читаются в коде, но еще больший гиморой возникает, когда это сертификаты по ГОСТ - Криптография по ГОСТ. Одна только процедура установки сертификата на Web-сервер чего стоит - Установка ГОСТ-сертификата на Web-сервер
  
  
• 21. Сайты, в которые надо ходить по SSL, например платежные системы, почти всегда отправляют уведомления по SSL. Чтобы запустить такой сайт на другой машине - нужно будет купить новый сертификат, перенастроить платежную систему и загрузить SSL-сертификат в IIS. Кстати, несколько платежных шлюзов я опубликовал у себя на сайте - Шлюзы к платежным системам интернет-денег
  
  
• 22. Существует довольно обширный класс задач, принципиально не решаемый на ASP.NET. Например задачи в которых постбек должен уходить непосредственно с клиента на другой сайт, да еще и в другой кодировке. Таких задач не так мало, как кажется - например такого алгоритма требуют многие платежные системы. В таком случае надо делать проходную форму на простом ASP - как например у меня сделано на //www.vb-net.com/Payment.aspx. В этом случае на целевой системе надо разворачивать не только хостинг ASP.NET-приложений, но и хостинг простого ASP - а в этом деле есть тоже свои вопросы.
  
  
• 23. Как правило, необходимо ставить разрешения на ключи реестра для учетных записей IIS. Например если сайт пишет что-то в системный журнал - надо ставить разрешения на HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\EventLog. Те сайты, которые вы можете сгрузить например у меня с http://products.vb-net.com/List.aspx все пишут в журнал системы критическую диагностику и, соответственно, требуют установки разрешения на указанный ключ реестра.
  
  
• 24. Многие ASP.NET сайты работают с использованием функционала SharePoint. Самый распросраненный такой сайт - Team Foundation Server, применяемых для синхронизации доступа нескольких программистов к единому депозитарию кода. У меня есть описание и Установка Team Foundation Server и вообще много ругни на Шарпоинт - Stop Microsoft. ASP.NET-сайты с такими приблудами как Team и SharePoint не только принципиально невозможно развернуть по Xcopy на SHARED-хостинге, но и на Dedicated-хостинге весьма непросто.
  
  
• 25. Если сайт вызывает COM-обьекты, то настройка безопасности в этом случае - тоже нетривиальная процедура. Такой сайт не получится легко запустить без предварительной настройки целевой среды запуска. Я описал эту процедуру настройки в разделе Формирование Excel-отчетов

Как вы видите, достичь заявленных микрософтом целей - Deploy ASP.NET applications using Xcopy невозможно. Или сформулируем иначе - запустить свое ASP.NET-приложение на ИНОЙ машине, кроме девелоперской весьма и весьма непросто.

Правда состоит в том, что вынести на SHARED-хостинг (или запустить ASP.NET-сайт на другом кампутере) возможно ТОЛЬКО в случае самых убогих студенческих проделок. Типо странички в одну кнопку, которая пишет "Ой, я счастлива - меня нашли и нажали!". Все остальные сайты, над которыми работал профессиональный программист хотя бы месяц - практически невозможно развернуть на SHARED-хостинге. И даже на виртуальном хостинге (те на другом Windows, которые доступен полностью) - развернуть ASP.NET сайт можно ТОЛЬКО с весьма и весьма основательной настройкой целевой среды запуска.

Все это резко контрастирует с настройкой и развертыванием PHP-приложений, где редко что-нибудь вообще приходится подправлять кроме PHP.INI. Эта проблема развертывания ASP.NET сайтов вообще шокирует PHP-программистов, которые вообще в подавляющем большинстве случаев вообще не понимают о чем вообще идет речь - так как их сайты без малейших проблем обычно заливаются на совершенно ЛЮБЫЕ SHARED-хостинги (в их терминологии на виртуальный хостинг Apache).

Наряду с дороговизной микрософтовских технологий (неприемлимым соотношением цена/качество) именно в сложности развертывания, непереносимости сайта, привязке сайта к каким-то глубинным настройкам Windows, утопленным не пойми куда - и кроется причина чрезвычайно низкой доли рынка, занятой ASP.NET-сайтами - всего 0,4%. И именно из-за этих причин многие успешные интернет-проекты сделаны именно на MONO, а не на билогейтсовской ASP.NET, например один из самых успешных интернет-проектов http://ru.wikipedia.org/, создатель которого недавно отчитался об очередных 70 миллионах долларов чистой прибыли. И именно поэтому в интернете появилась масса вот-таких программистов, работающих не на классической микрософтовской ASP.NET, а именно на MONO.

Если же для вас важна переносимость вашего ASP.NET-приложения на другой кампутер, общая легкость приложения без привязки к глубинным особенностям операционной системы - я бы порекомендовал использовать вам MONO - Low cost and platform independent ASP.NET - be free with MONO. Сайты, сделанные на MONO, обычно не только легко запускаются на другом Windows-кампутере, но даже в принципиально другой среде - на Макинтошах, в Солярисе, под Windows 95, на игровых приставках XBOX, на самых современных ныне существующих суперкомпьютерах IBM, даже на всяких встроенных бездисковых системах и так далее почти до бесконечности:

<SITEMAP>  <MVC>  <ASP>  <NET>  <DATA>  <KIOSK>  <FLEX>  <SQL>  <NOTES>  <LINUX>  <MONO>  <FREEWARE>  <DOCS>  <ENG>  <CHAT ME>  <ABOUT ME>  < THANKS ME>