Позади остались майские праздники, Крым и горы. И даже пара рабочих недель, чтобы перестать скучать по работе после отпуска ... Чудесное кстати ощущение - уходить и радоваться, что уходишь, а потом возвращаться к компьютеру - и радоваться, что возвращаешься :)

Так что я снова рад вас видеть! Итак, переворачиваем страницу и попадаем на следующий выпуск ...


Но сначала новости ...

Осталась неделя до завершения Bench Games II. Для тех кто не в курсе, напомню: сервер Brainbench открыл бесплатный доступ ко всем своим тестам на период соревнований с 15 по 31 мая. Каждый, кто за этот период наберет больше всех баллов по любому из тестов, становится победителем и получает годовую подписку на Brainbench. Кроме того, среди победителей (их должно быть около 500) будут розыграны три плейра iPod.

Сейчас доступна Leader Board, где публикуется текущий рейтинг как отдельных участников, так и стран в целом. Приятно видеть, что Украина показывает себя вполне достойно - в конце концов с Индией (своеобразной програмистской Финлядией - все смеются, но отдают ей первое место, нет, Евровидение - это,блин, просто ... сорри, отвлекся ...) бороться бесполезно :) Кстати, ни для кого не секрет, что существует большое количество шуток и историй про индийских программистов. Но вот недавно, наши американские заказчики вполне серьезно пожаловались, что существует даже специальный термин - "микро-менеджмент", придуманный именно для индусов. Это когда при выполнении задачи они настолько подробно уточняют малейшие детали и подробности, что затраты на менеджмент намного перекрывают выгоду от более дешевой стоимости работы.

Да, так вот о Bench Games II. Для кого-то оставшаяся неделя можеть быть шансом оказаться в числе победителей (если вы уже не там :) - еще не по всем тестам набрано 5.0 баллов, а для кого-то - просто возможностью бесплатно сдать интересующие его экзамены. Кстати, по поводу 5.0 баллов - у меня создалось впечатление, что некоторые участники чуть ли не с секундомером следили за началом соревнований, чтобы первыми пройти тест и обеспечить себе гарантированную победу, набрав 5.0 Когда утром, в день открытия игр, я пришел на работу, мне сразу же рассказали, что экзамен по C# (тут у меня были все шансы набрать максимум баллов) уже кем-то сдан. Фраза, которой мой приятель обрисовал мне ситуацию, здорово напоминала анекдот "Запомни, в армии нет слова спиз#@ли, в армии есть слово прое#@л!" :) Так что мне пришлось вздохнуть и постараться вспомнить более давние и уже слегка устаревшие темы, на которые не набрасывались в первую очередь. Кстати, если вы просмотрите индивидуальный список лидеров, то пока (там все таки нету 5.0, а соревнования еще не закончены) сможете найти мое имя рядом с названиями "ActiveX", "Visual C++" и "Web Development Concepts" :)

Вобщем у вас впереди еще целая неделя, удачи!

А теперь вернемся к нашей теме.
Вы вспомнили стихотворение Маршака? О том сколько возни пришлось пережить грузчикам, носильщикам и самой даме, пока она добиралась до вожделенного Житомира? Очень часто web проекты содержат такое количество вспомогательны файлов, что работа носильщика показалась бы просто синекурой, по сравнению с работой "деплойщика" проектов. Как правило, это разнообразные ресурсные файлы: изображения (.jpg, .gif), таблицы стилей (.css), клиентские скрипты (.js).

Нельзя сказать, что они доставляют слишком много проблем, но ... как всегда хочется чего-то более изящного и простого. Посмотрим, что появилось в этом отношении с приходом .NET Framework 2.0.

В ASP.NET 2.0 появилась возможность встраивать ресурсные файлы непосредственно в исполнимый файл вашего web прилолжения - .dll.
- Что же тут нового? - удивитесь вы. Дело в том, что речь идет о клиентских ресурсах - скриптах, изображениях, которые можно указать в аттрибуте "src" или "href" html кода и они будут обрабатываться, как будто расположены в отдельных .js или .gif файлах на сервере - отдаваться браузеру и корректно кэшироваться.
Что же для этого нужно сделать?

1. Добавить ресурс (например Utilites.js файл) к проекту. Установить его свойство "Build Action" в значение "Embedded Resource" - тогда он будет встроен в .dll файл.
   
   
2. Указать, что данная .dll содержит ресурс, который может быть запрошен извне. Для этого нужно использовать аттрибут WebResourceAttribute, например вот так:
   
   

   [assembly: WebResourceAttribute ("Utilities.js", "application/x-javascript",false)]

   
   Первый и второй параметры очевидны, с третьим немного сложнее, о нем я расскажу чуть позже. Сама же регистрация ресурса нужна прежде всего из соображений безопасности - из всех встроенных ресурсов вы явно указываете только те, к которым разрешен доступ.
   
   
3. Добавить в формируемый html ссылку на встроенный ресурс. Тут у нас два варианта, если мы встроили файл с клиентскими скриптами и нам нужно нечто типа:
   
   

   <script language="javascript" src="/library/Utilities.js"></script>

   
   Используйте для его регистрации метод Page.ClientScript.RegisterClientScriptResource, он сделает все что нужно. Если же мы встроили какое-либо изображение (например Logo.gif) и хотим использовать его в теге типа <img src="/Img/Logo.gif" />, для получения значения attribute "src" используйте вызов Page.GetWebResourceUrl.

Теперь о третьем параметре аттрибута WebResourceAttribute. Он называется "PerformSubsitution". Установка этого аттрибута в true позволяет использовать во встроенных ресурсах ссылки на другие встроенные ресурсы. Пример? Допустим у нас есть .css файл со стилями, мы встраиваем его в .dll и подключаем к html странице. Однако, эти стили могут содержать ссылки на другие ресурсы, также встроенные в .dll, например:

.NtbInputSilver {   background-image: url(<% = WebResource("MyProject.Logo.gif")%>); }

Вот как раз чтобы разрешить ссылки на другие встроенные ресурсы, при регистрации .css файла нужно установить третий параметр аттрибута WebResourceAttribute в true, например:
[assembly :WebResourceAttribute("MyProject.Style.css", "text/css", true)]

Однако этот параметр нужно использовать осторожно - из-за ошибки в реализации такое решение может работать некорректно. В двух словах, после выполнения подстановки у объекта StringWriter не вызывается метод Close, из-за чего часть данных может потеряться. Для исправления этой ошибки можно посоветовать добавить пробелы или комментарии к встроенному ресурсу так, чтобы его размер превысил 1024 байта - длина буфера, используемого объектом StringWriter по умолчанию. Тогда буфер будет гарантированно сохранен. Да, это конечно не самое красивое решение, но у него есть один большой плюс - он работает :)

Подводя итоги, можно сказать, что данная технология позволяет распространять приложения в виде одних только .dll файлов, что может может оказаться особенно полезным для элементов управления. Если вы создали какой-то control, согласитесь, очень удобно распространять его в виде единственной .dll со встроенными ресурсами, а не в виде целого набора .js, .gif и .css файлов.

Это коночно была только общая идея, если вы действительно заинтересовались - советую прочитать вам статью " Handling Client Files in ASP.NET Whidbey" в которое все это подробно описано.

Так же, стоит упомянуть об утилите ILMerge. Она позволяет склеивать несколько .NET сборок в одну единственную сборку.

А вот в этом посте Jomo Fisher объясняет, как настроить Visual Studio 2005 так, чтобы проект сам собирал все бинарные файлы в один после компиляции.

Так что теперь есть шансы, что вместо четырех зеленых квитанций на станции вам вручат только одну. А strong name of assembly помешает администрации хостинга сказать вам с милой улыбкой "Однако за время пути, программа могла подрасти!" :)

Удачи вам, счастливо и - как всегда до следующей встречи!