Добавить любую из этих подпапок в Web-приложение можно явно, выбрав WebSite→Add Folder из меню. Но во многих случаях это сделает сама среда разработки, как только вы "естественным образом" добавите соответствующий файл (например, при добавлении в систему узла нового файла C#, автоматически в структуру каталогов добавляется папка App_Code, если она в этот момент не существует).
Роль папки Bin
Позже вы увидите, что Web-страницы ASP.NET в конечном счете компилируются в компоновочный блок .NET. Поэтому не должно быть неожиданностью то, что Web-узлы могут ссылаться на любое число приватных или общедоступных компоновочных блоков, В ASP.NET 2.0 метод указания внешних компоновочных блоков, необходимых для данного узла, в корне отличается от того, что предлагалось в рамках ASP.NET 1.x. Причина такого изменения в том, что теперь в Visual Studio 2005 Web-узлы трактуются в беспроектной форме.
Хотя шаблон Web Site и генерирует файл *.sln, с помощью которого можно загрузить файлы *.aspx в среду разработки, связанного с ним файла *.csproj не существует. Вы, возможно, знаете, что проект Web-приложения ASP.NET 1.x записывал информацию обо всех внешних компоновочных блоках в файл *.csproj. Этот факт порождает резонный вопрос: "Где хранится информация о внешних компоновочных блоках в ASP.NET 2.0?"
Когда вы ссылаетесь на приватный компоновочный блок, Visual Studio 2005 автоматически создает каталог Bin в структуре каталогов приложения, чтобы сохранить там локальную копию двоичного файла. При использовании вашим программным кодом типов из соответствующих библиотек программного кода они автоматически загружаются по первому запросу. Для проверки активизируйте меню WebSite→Add Reference и выберите любой (но не строго именованный) файл *.dll из тех, которые вы создали в процессе изучения текста этой книги, и вы обнаружите, что в окне Solution Explorer отображается папка Bin (рис. 23.14).
Рис. 23.14. Папка Bin содержит копии всех приватных компоновочных блоков, на которые ссылается приложение
Если же вы ссылаетесь на общедоступный компоновочный блок, Visual Studio 2006 автоматически добавляет в текущее Web-решение файл web.config (если его еще нет) и записывает внешнюю ссылку в рамках элемента ‹assemblies›. Так, если снова активизировать меню Site→Add Reference, но на этот раз выбрать общедоступный компоновочный блек (например. System.Drawing.dll), то вы обнаружите, что ваш файл Web.config примет следующий вид.
‹?xml version="1.0"?›
‹configuration xmlns="http://schemas.microsoft.com/.NetConfiguration/v2.0"›
‹appSettings/›
‹connectionStrings/›
‹system.web›
‹compilation debug="false"›
‹assemblies›
‹add assembly="System.Drawing, Version=2.0.0.0, Culture=neutral, PublicKeyToken=B03F5F7F11D50A3A"/›
‹/assemblies›
‹/compilation›
‹authentication mode="Windows"/›
‹/system.web›
‹/configuration›
Как видите, каждый компоновочный блок описывается с помощью той же информации, которая требуется для динамической загрузки через метод Assembly.Load() (см. главу 12).
Роль папки App_Code
Папка App_Code используется для хранения файлов исходного кода, которые не привязаны непосредственно к конкретной Web-странице (как файлы с внешним кодом поддержки), но которые все равно должны компилироваться для использования вашим Web-узлом. Программный код из папки App_Code будет автоматически компилироваться в фоновом режиме по мере необходимости. После этого соответствующий компоновочный блок становится доступным любому другому программному коду Web-узла. В этом смысле папка App_Code во многом подобна папке Bin, за исключением того, что здесь вы можете сохранить исходный код вместо скомпилированного программного кода. Главным преимуществом такого подхода является то, что оказывается возможным определить пользовательские типы для Web-приложения без необходимости компилировать их независимо.
Одна папка App_Code может содержать файлы программного кода, созданные на разных языках. В среде выполнения подходящий компилятор сгенерирует нужный компоновочный блок. Если же вы предпочитаете хранить такие файлы программного кода раздельно, можете определить множество подкаталогов для хранения файлов с управляемым программным кодом разного типа (*.cs, *.vb и т.д.).
Для примера предположим, что вы добавили в корневой каталог приложения Web-узла папку App_Code, содержащую две подпапки (MyCSharpCode и MyVbNetCode), которые содержат файлы, написанные на соответствующих языках. После этого вы можете создать файл Web.config, который указывает на эти подпапки с помощью элемента ‹codeSubDirectories›.
‹?xml version="1.0"?›
‹configuration xmlns="http://schemas.microsoft.com/.NetConfiguration/v2.0"›
‹appSettings/›
‹connectionStrings/›
‹system.web›
‹compilation debug="false"›
‹assemblies›
‹add assembly="System.Drawing, Version=2.0.0.0, Culture=neutral, PublicKeyToken=B03F5F7F11D50A3A"/›
‹/assemblies›
‹codeSubDirectories›
‹add directoryName="MyCSharpCode" /›
‹add directoryName="MyVbNetCode" /›
‹/codeSubDirectories›
‹/compilation›
‹authentication mode="Windows"/›
‹/system.web›
‹/configuration›
Замечание. Папка App_Code часто используется и для хранения файлов, которые не являются файлами c программным кодом на конкретном языке, но тоже оказываются необходимыми (например, файлы *.xsd, *.wsdl и т.д).
Цикл компиляции страницы ASP.NET 2.0
Независимо от того, какую модель страницы вы использовали (одномодульную страницу или страницу с внешним кодом поддержки), ваши файлы *.aspx (как и любые связанные файлы с кодом поддержки) динамически компилируются в действительный компоновочный блок .NET. Этот компоновочный блок затем обрабатывается в рамках рабочего процесса ASP.NET (aspnet_wp.exe) в пределах собственного домена приложения (для получения более подробной информации о доменах приложений см. главу 13). Однако метод компиляции компоновочного блока Web-узла в ASP.NET 2.0 оказывается совершенно иным.
Цикл компиляции одномодульных страниц
При использовании модели одномодульной страницы, HTML-разметка, блоки ‹script› и определения Web-элементов управления динамически компилируются в тип класса, производный от System.Web.UI.Page.
Имя этого класса получается из имени файла *.aspx с помощью присоединения суффикса _аspx к имени файла (например, страница MyPage.aspx порождает тип класса с именем MyPage_aspx). На рис. 23.15 показана общая схема соответствующего процесса.
Рис. 23.15. Модель компиляции одномодульных страниц
Этот динамически компилируемый компоновочный блок устанавливается в определенный средой выполнения подкаталог в папке ‹%windir%›Microsoft.NET Frameworkv2.0.50215Temporary ASP.NET Filesroot. Имя пути после root зависит от целого ряда факторов (хеш-кода и т.п.). но в конце концов там можно найти соответствующие файлы *.dll (и файлы поддержки). На рис. 23.16 показан пример одного такого компоновочного блока.
Рис. 23.16. Автоматически сгенерированный компоновочный блок ASP.NET
Цикл компиляции многомодульных страниц
Процесс компиляции страницы, построенной по модели с внешним кодом поддержки, подобен процессу компиляции одномодульной страницы. Однако получающийся при этом тип, производный от System.Web.UI.Page, компонуется из трех файлов (да, именно из трех, а не из ожидаемых двух).
Взглянув на предыдущий пример CodeBehindPageModel, вспомните о том, что файл Default.aspx связывается с парциальным классом _Default, размещенным в файле внешнего кода поддержки. Если вы имеете опыт работы с ASP.NET 1.x, то можете спросить, что же при этом происходит с описаниями членов-переменных для различных Web-элементов управления и с программным кодом в пределах InitializeComponent(), в частности с программной логикой обработки событий. В ASP.NET 2.0 все это собирается в третьем "файле", генерируемом в памяти. Фактически это не совсем файл, а представление парциального класса в памяти (рис. 23.17).
В рамках этой модели объявленные в файле *.aspx Web-элементы управления используются для построения дополнительного парциального класса, определяющего все члены-переменные интерфейса пользователя и программную логику конфигурации, которые в ASP.NET 1.x обычно находились в пределах метода InitializeComponent(), а в данном случае остаются для нас невидимыми. Этот парциальный класс в процессе компиляции объединяется с файлом внешнего кода поддержки, чтобы в результате получился базовый класс генерируемого типа класса _aspx (в модели компиляции одномодульной страницы генерируемый файл _aspx получается непосредственно из System.Web.UI.Page).
В любом случае после создания компоновочного блока в ответ на исходный HTTP-запрос этот компоновочный блок будет использоваться многократно для всех последующих запросов, не требуя перекомпиляции. Вот почему первый запрос страницы *.aspx может занимать много времени, а последующие обращения к той же страницы оказываются намного быстрее.
