Регистрация элементов управления осуществляется директивой @Register, которая позволяет использовать в HTML коде страницы user controls и server controls, используя специальный синтаксис (declarative custom server control syntax). Парсер страниц на основе анализа этих директив может связывать теги с заданными типами и при создании страницы встраивать элементы управления уже как контейнеры пользовательских типов – ветви дерева элементов управления страницы.

Директивы должны предшествовать первому использованию объявляемых тегов, чаще их размещают в начале страницы и в случае регистрации нескольких элементов управления, в сайтах с модульной структурой количество таких объявлений может занимать большое количество строк. При изменении расположения элементов управления приходится искать требующие изменения строки в коде всех страниц и пользовательских элементов управления, на которых они зарегистрированы, что довольно неудобно.

В статье описан способ, упрощающий регистрацию элементов управления.

Для директив регистрации мы будем использовать обычный текстовый файл, в котором соберем все директивы @ Register. Так как для объявления user controls можно использовать виртуальные пути, а для server controls указываются лишь пространства имен, мы можем собрать в этом файле все нужные нам ссылки, причем ссылки на файлы ascx будут верными для любой папки проекта. Вот как выглядит этот файл в одном из проектов:

<%@ Register TagPrefix="ch" Namespace="ControlsSharp.HtmlControls" Assembly="ControlsSharp"%>

<%@ Register TagPrefix="cw" Namespace="ControlsSharp.WebControls" Assembly="ControlsSharp"%>

<%@ Register TagPrefix="c" Namespace="ControlsSharp.CustomControls" Assembly="ControlsSharp"%>

<%@ Register TagPrefix="b" Namespace="ControlsBasic.CustomControls" Assembly="ControlsBasic"%>

<%@ Register TagPrefix="cu" TagName="bottommenu" Src="~/UserControls/Menu/cu_menu_bottom.ascx" %>

<%@ Register TagPrefix="cu" TagName="leftmenu" Src="~/UserControls/Menu/cu_menu_left.ascx" %>

<%@ Register TagPrefix="cu" TagName="topmenu" Src="~/UserControls/Menu/cu_menu_top.ascx" %>

Назовем файл register.inc и поместим в папку /inc нашего веб-проекта.

Этот файл будет содержать все нужные нам ссылки, добавление или изменение регистрации пользовательского или серверного элемента управления мы будем осуществлять именно в нем.

Теперь созданный файл нужно каким-то образом включить в код страницы. Мы сделаем это с помощью директивы SSI (server side includes) #include. Эта директива позволяет включать в код страницы статические и динамические файлы, обрабатывая их на основе маппинга IIS, т.е. указание в качестве источника файла asp или aspx приведет к обработке файла соответствующим процессом и копированию результатов этой обработки в выдаваемую страницу. В ASP директива #include очень широко использовалась и позволяла реализовать модульность сайта. С появлением ASP.NET это стало удобнее делать другими способами, например, с помощью user controls. В следующих версиях ASP.NET модульность будет реализована с использованием master pages. В общем, директива #include потеряла свое значение и была сохранена в основном для обратной совместимостью и для упрощенной миграции ASP проектов на .Net.

Так как у нас простой текстовый файл, никакой обработки произведено не будет, и до выполнения любого динамического контента все содержимое файла будет скопировано в код страницы. Т.е. добавление нашего файла register.inc, например, в начало страницы, это почти то же самое как будто бы мы напишем там все директивы @ Register.

Для того чтобы не зависеть от физического размещения файла, мы снова используем синтаксис с указанием виртуального пути и добавим в код aspx файла вот такую строчку:

<!--#include virtual="/inc/register.inc" -->

Убедитесь, что все работает, если нет, поправьте неверно указанные пути.

Осталось осуществить еще одну операцию. Сейчас, если вы попробуете по ссылке в браузере получить файл /inc/register.inc, вы без труда сможете это сделать. IIS отдает его в ваши руки, так же как в руки злоумышленника, совершенно свободно, хотя там содержатся пути физической структуры вашего сайта.

Для того чтобы этого не происходило, мы используем возможности синхронного обработчика HttpForbiddenHandler, позволяющего защищать файлы определенного типа от выдачи по запросам пользователя. Этот подход удобен и часто используется, например, для защиты файлов баз данных MS Access, используемых в проекте. Для того чтобы файлы с расширение *.inc можно было защитить с помощью этого обработчика нужно сообщить IIS что эти файлы будет обрабатывать процесс ASP.NET, другими словами настроить в IIS маппинг на файлы этого типа.

Подробное описание процесса настройки для IIS описано в статье HOW TO: Use ASP.NET to Protect File Types (http://support.microsoft.com/kb/815152/EN-US/). Нам потребуется создать маппинг только для файлов типа *.inc. После выполнения описанных там шагов, все запросы к файлам с таким расширением будут обрабатываться процессом ASP.NET, и вам останется отредактировать файл web.config следующим образом:

<?xml version="1.0" encoding="utf-8" ?>

<configuration>

<system.web>

<httpHandlers>

<add verb="*" path="*.inc" type="System.Web.HttpForbiddenHandler" />

</httpHandlers>

</system.web>

</configuration>

Все, теперь при попытке получить файл /inc/register.inc по прямой ссылке пользователь получит ошибку В[This type of page is not served.В].

Чтобы не регистрировать aspnet_isapi.dll, например, ваш провайдер не хочет этого делать можно воспользоваться возможностью SSI указывать файлы любого типа и схитрить, использовав для файла с директивами @Register расширение одного из типов, уже маппированных в IIS по умолчанию. Для этого будут удобны расширения *.cs или *.vb. Эти файлы содержат исходный код и обычно не копируются на сервер. Если вы вдруг ошиблись и скопировали, по запросу из браузера их получить не удастся, - при попытке это сделать пользователь получит ошибку В[This type of page is not served.В]. Так происходит потому, что для фалов этого типа маппинг в IIS настроен по умолчанию а соответствующее расширение уже прописано в секции <httpHandlers> файла machine.config. В Visual Studio для того чтобы компилятор не выдавал вам сообщение об ошибке, поставьте расширение которое компилятор не интересует: в проектах на C# это *.vb, в проектах VB - *.cs.
Заключение

Описанный способ позволяет регистрировать элементы управления в одном месте для всего проекта. Последующая модификация этого файла требует меньше усилий по сравнению с тем, как если бы пришлось делать это обычным способом. Попробуйте использовать SSI #include внутри самих вставляемых файлов – это позволяет организовать подобие иерархии и наследования, что может быть удобно для крупных проектов.