Посмотрел на днях презентацию c конференции MIX ASP.NET 4.0: What's Next?, которую проводил Stephen Walter (Senior Program Manager at Microsoft). Должен сказать, что улучшения в следующей версии ASP.NET, а также в Visual Studio 2010, приятно удивили. Что же нового нам готовит ASP.NET 4.0?

Помнится где-то год назад мне задали вопрос о том, как IIS сервер обрабатывает запросы. Не буду лукавить, тогда я затруднился с ответом. Но прошло уже немало времени за которое удалось получить необходимые знания, сообственно, которыми и хочу поделиться.

ISAPI-расширения

Разные типы запросов (имеются ввиду расширения, например, .html, .aspx) IIS (Internet Information Services) сервер обрабатывает по разному. Например, расширения .html IIS сервер может обработать сам. Для обработки таких расширений как .aspx, .asmx, .ashx используется специальный компонент ISAPI-расширение (Internet Server Application Programming Interface), в данном случае aspnet_isapi.dll, которое используется как в IIS5 так и IIS6. Связать новый тип расширения файла с модулем ISAPI можно в настройках IIS.

От IIS до ASP.NET

Процесс обработки клиентского запроса на сервере начинается с драйвера Http.sys, который прослушывает входящие HTTP-запросы. Для наглядности схема обработки запроса показана на следующем рисунке.

IIS5
В данной версии IIS сервера все расширения выполняются в рамках процесса inetinfo.exe. Для взаимодействия с расширениями используются именованые каналы (named pipes), что, сообственно, не повышает производительности. В связи с тем, что при обработке запроса приходится пересекать границы нескольких процессов, создаются дополнительные накладные расходы. Да и загрузка в контекст процесса inetinfo.exe всех расширений может привести к сбою сервера в случае выхода из строя одного из них.

IIS6
Начиная с Windows 2003 драйвер драйвера Http.sys был интегрирован на уровне ядра Windows. В Windows 2003 также был добавлен Web Administration Service (WAS), который проверяет расширения запросов. Если запрос предназначается ASP.NET-приложению (.aspx, .asmx, .ashx-расширения), WAS создает рабочий процес w3wp.exe и передает в него запрос, в ином случае запрос передаётся в IIS. Благодаря этому обработка запроса происходит быстрее, потому что нет лишних обращений через границы процессов.

После создания рабочего процесса в него загружается среда выполнения .NET, именно рабочий процесс является хостом CLR. После того, как CLR была запущена и сконфигурирована нужным образом, происходит вызов метода ISAPIRuntime.ProcessRequest, который можно сказать и является точкой входа в ASP.NET. Данный метод создает обьект класса HttpWorkerRequest, который потом передаётся в статический метод HttpRuntime.ProcessRequest.
На данный момент существуют три класса, реализующие HttpWorkerRequest.

Ну а далее класс HttpRuntime создаёт обьект HttpContext. HttpContext в свою очередь, создаёт HttpRequest, HttpResponse. После этого через фабрику HttpApplicationFactory создается новый экземпляр HttpApplication. В него загружается его состояние, то есть объект класса HttpApplicationState. Далее выполняется инициализация HttpApplication.

Затем запросы пересылаюся на HTTP-модули, которые могут выполнить предварительную обработку перед запуском обработчика. После выполнения обработчика запрос снова пересылается на модули, которые могут выполнить заключительную обработку.
После того, как запрос был полностью обработан, экземпляр HttpApplication может быть помещён в пул, если на момент помещения размер пула не превысил 100 экземпляров (интересно почему данное число прописано хардкодом в классе HttpApplicationFactory?!), иначе все ресурсы, используемые этим обьектом, освобождаются, в том числе и Http-модули. У каждого из них вызывается метод Dispose.

Модули HTTP

Одним из средств расширения, которое предоставляет ASP.NET, являются HTTP-модули. С помощью HTTP-модулей можно подписаться на события, которые генерит класс HttpApplication и таким образом управлять обработкой HTTP-запросов. Для реализации сообственного HTTP-модуля нужно реализовать интерфейс

[code=c#]public interface IHttpModule

{
    void Dispose();
    void Init(HttpApplication context);
}[/code] В методе Init можно подписаться на события, которые генерирует класс HttpApplication.
 

 Следующие события вызываются в неопределённом порядке:

Чтобы HttpApplication знал о существовании модуля, его необходимо зарегистрировать в web.config.

Пример регистрации HTTP-модуля:
[code=xml]<httpModules>
    <add name="ScriptModule" type="System.Web.Handlers.ScriptModule, System.Web.Extensions"/>
 </httpModules>[/code]

Обработчики HTTP

Другим средством расширения ASP.NET являются HTTP-обработчики (HttpHandler), которые обрабатывают определённый тип запросов. Чтобы создать свой обработчик нужно реализовать интерфейс
[code=c#]public interface IHttpHandler
{
     bool IsReusable { get; }
     void ProcessRequest(HttpContext context);
}[/code]Метод ProcessRequest выполняет непосредственную обработку запроса, а свойсто IsReusable указывает на то, может ли экземпляр даного класса использоваться повторно для других запросов. При IsReusable=false каждый раз будет создаваться новый экземпляр. Как и в случае с HTTP-модулями, HTTP-обработчики нужно зарегистрировать в конфигурационном файле. Пример:
[code=xml]<httpHandlers>
    <remove verb="*" path="*.asmx"/>
    <add verb="GET,HEAD" path="ScriptResource.axd" type="System.Web.Handlers.ScriptResourceHandler, System.Web.Extensions" validate="false"/>
</httpHandlers>[/code]Параметр path задает маску ресурсов, запросы к которым будут обрабатываться данным обработчиком. Verb задает типы HTTP-запросов, которые будут перенаправляться обработчику, например, "GET", "POST", "*" (включает любые типы запросов). Атрибут type указывает имя класса обработчика.
В корневом файле web.config (%SystemRoot%\Microsoft.NET\Framework\v%CLRVersion%\CONFIG) определены основные HTTP-обработчики:
[code=xml]<httpHandlers>
    <add verb="*" path="*.rules" type="System.Web.HttpForbiddenHandler" validate="true"/>
    <add path="trace.axd" verb="*" type="System.Web.Handlers.TraceHandler" validate="True"/>
    <add path="*.axd" verb="*" type="System.Web.HttpNotFoundHandler" validate="True"/>
    <add path="*.aspx" verb="*" type="System.Web.UI.PageHandlerFactory" validate="True"/>
    <add path="*.ashx" verb="*" type="System.Web.UI.SimpleHandlerFactory" validate="True"/>
    <add path="*.asax" verb="*" type="System.Web.HttpForbiddenHandler" validate="True"/>
    <add path="*.ascx" verb="*" type="System.Web.HttpForbiddenHandler" validate="True"/>
    <add path="*.master" verb="*" type="System.Web.HttpForbiddenHandler" validate="True"/>
    <add path="*.skin" verb="*" type="System.Web.HttpForbiddenHandler" validate="True"/>
    <add path="*.browser" verb="*" type="System.Web.HttpForbiddenHandler" validate="True"/>
    <add path="*.sitemap" verb="*" type="System.Web.HttpForbiddenHandler" validate="True"/>
    <add path="*.dll.config" verb="GET,HEAD" type="System.Web.StaticFileHandler" validate="True"/>
    <add path="*.exe.config" verb="GET,HEAD" type="System.Web.StaticFileHandler" validate="True"/>
    <add path="*.config" verb="*" type="System.Web.HttpForbiddenHandler" validate="True"/>
    <add path="*.cs" verb="*" type="System.Web.HttpForbiddenHandler" validate="True"/>
    ....
</httpHandlers>[/code]

Примечание

Связывая новый тип расширения файла с HTTP-обработчиком, нужно ещё связать это расширение в IIS с модулем aspnet_isapi, для того чтобы запрос не блокировался на уровне сервера, а перенаправлялся ASP.NET.
 

Ссылки по теме:

http://www.rsdn.ru/article/dotnet/insideaspnet.xml - когда этот пост был уже на половину готов, я обнаружил вот эту статью на RSDN. Поэтому, если интересно более детальное описания взаимодействия IIS и ASP.NET, рекомендую к прочтению.
http://www.15seconds.com/Issue/020417.htm
http://www.theserverside.net/tt/articles/showarticle.tss?id=IIS_ASP
http://www.programmersheaven.com/2/a-low-level-look-at-the-asp-page-2     

Некоторое время назад, когда я писал дипломную работу, помнится одним из необязательных заданий в дипломе был форум. К сожалению, времени на создание своего форума тогда совсем не было. Поиск же существующих бесплатных разработок на ASP.NET ни к чему не привёл и, соответственно, диплом остался без форума.

Сегодня чисто случайно наткнулся вот на такую разработку yetanotherforum.net .  Тестовый вариант можно посмотреть здесь.

YetAnotherForum.NET (YAF) - это open source форум, предоставляемый под лицензией GPL, более детально на сайте разработчиков.

Размер архива с исходниками 1,58.

Как известно, чтобы получить доступ к классу из другой сборки, этот класс должен быть обьявлен как public. Однако такие действия не всегда являются лучшим решением, так как в результате классом может воспользоваться кто угодно. Существует и другой модификатор доступа  - internal. Пометив класс как internal, область его видимости ограничивается сборкой в которой он обьявлен. Иногда же возникает необходимость объединить эти два подходы, то есть класс должен быть видим только внутри сборки, где он определён, и в некоторых случаях вести как public. Хорошим пример может послужить разбиение приложения на слои (layer), где каждому слою соответствует отдельная сборка. До появления .NET Framework 2.0 единственным выходом из этой ситуации было определения класса как public, но с выходом последнего появился специальный атрибут InternalsVisibleTo, который позволяет делать сборки "дружественными".

Например, у нас есть сборка А, классы которой помечены как internal. Для того чтобы сборка В могла обращаться к internal классам сборки А, в последнюю нужно добавить атрибут

[code=c#][assembly: InternalsVisibleTo("'имя сборки В', PublicKey='публичный ключ'")].[/code]

Применение данного атрибута распространяется как на internal классы, так и на методы, свойства.

PS: использовать данный атрибут можно и в юнит-тестах, когда необходимо протестировать internal методы. Кстати, майкрософтовцы и сами широко используют данный атрибут, как пример сборка System.Data, посмотрите рефлектором.

Зачем это нужно?
В том случае, когда solution состоит из нескольких проектов и необходимо для всех сборок вручную поменять версию, задача превращается в рутинную работу. Если же выполнить ниже указанные действия, то изменять версию придётся только в одном файле.

Как это сделать?
1. Создаём AssemblyInfo.cs и ложим его в общую папку.
2. Добавляем существующий файл в каждый проект как ссылку (см. рисунок ниже).

PS: данный пост я разместил больше для себя, так как от проекта к проекту проходит немало времени и я постоянно умудряюсь забывать, что нужно делать.