Поддерживает ли сборка свою структуру каталогов?

Question

1. Поскольку все файлы в веб-проекте скомпилированы в одну сборку, поддерживает ли эта сборка структуру каталогов? Например, если файл в корневом каталоге ссылается на файл в подкаталоге, то как эта ссылка может быть действительной, если два файла скомпилированы в одну сборку?

2. Предположим, что веб-проект имеет структуру каталогов, показанную ниже. Поскольку все ASPX-файлы веб-проекта скомпилированы в одну сборку WebProject1.dll, как эта сборка может записывать / запоминать структуру каталогов? Таким образом, когда вы развертываете WebProject1.dll на веб-сервере и пользователь делает запрос на http://WebProject1/some_SubDir/default.aspx, как WebProject1.dll сможет определить, какую страницу отображать?

   WebProject1 \ SubDir (где WebProject1 - корневой каталог) WebProject1 - содержит несколько файлов ASPX WebProject1 \ SubDir - содержит файл default1.aspx.

3. Когда мы разворачиваем веб-проект, должны ли мы создавать такую ​​же структуру каталогов на веб-сервере (WebProject1\SubDir), даже если мы не будем помещать какие-либо файлы ASPX в эти каталоги?

4. Я предполагаю, что на веб-сервере WebProject1.dll должен быть помещен в каталог Bin?

1031 * спасибо *

EDIT:

В сборку компилируется только исходный код, вам все равно нужно загрузить файлы aspx в соответствующий каталог на сервере.

В моей книге сказано, что при использовании веб-проекта весь веб-код компилируется в одну сборку. Я думал, что «весь код» включает в себя файлы aspx?!

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

Так что, если я добавлю новую страницу aspx через Project -> Add New Item и сохраню эту страницу aspx в подкаталоге с именем Hey , то эта страница будет находиться в пространстве имен WebProject1.Hey ?!

Но как мне добавить новый элемент в подкаталог, поскольку Проект -> Добавить новый элемент не дает мне возможности просмотреть и выбрать каталог, в котором я хочу его сохранить, но вместо этого автоматически создает файл aspx в корневом каталоге?

Относительный путь сохраняется, когда компилятор генерирует dll.

Я не уверен, что знаю, на какой относительный путь вы ссылаетесь?

1080 * спасибо *

Answer 1

В сборку компилируется только исходный код, вам все равно нужно загрузить aspx-файлы в соответствующий каталог на сервере. Например, ваш проект в Visual Studio может выглядеть следующим образом:

WebProject1 (The root project)
  |
  |- some_SubDir (A physical directory inside the project)
      |
      |-default1.aspx
      |-default1.aspx.cs (assuming a C# project)

После того, как вы скомпилировали веб-приложение, вам необходимо загрузить на сервер следующее:

WebProject1 (The root directory for your website)
 |
 |-bin (The binary directory created by the build)
    |
    |-WebProject1.dll (The compiled source code of the web app)
 |-some_SubDir
    |
    |-default1.aspx (The file that will map to the URL www.websitename.com/some_subdir/default1.aspx)

Скомпилированные ресурсы (файлы не из исходного кода, которые компилируются и хранятся в сборке) - это разные проблемы, которые рассматриваются в вашем другом вопросе

---

Отредактировано для добавления прямых ответов на вопросы:

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

2. Ваш файл default1.aspx будет иметь в заголовке что-то вроде:

Строка наследования сообщает веб-серверу, что когда пользователь запрашивает эту страницу, она должна обрабатываться вместе с исходным кодом, который определяет этот класс, который он найдет внутри скомпилированной сборки. Комбинация физического файла aspx и скомпилированного класса создаст стандартный html, который затем передается обратно клиенту.

3. Да, вам нужно создать ту же структуру каталогов, но вы обязаны поместить туда файлы aspx.

4. Да

(кто-то может отредактировать это, если он знает, как правильно составить нумерацию пунктов списка?)

Answer 2

Обратите внимание, что some_Subdir / default1.apsx имеет пару ключ / значение «Наследовать» в объявлении страницы?

Это означает, что когда вы делаете запрос на этот ресурс, IIS говорит: «Ага! Asp.Net должен обработать этот запрос! Привет asp.net, пожалуйста, верните мне немного HTML, чтобы отправить вниз

Asp.net анализирует этот файл aspx и на лету создает прокси-класс, который наследуется от WebProject1.some_Subdir._Default1. Затем этот прокси-класс анализирует дерево элементов управления и HTML и запускает жизненный цикл страницы (это слишком упрощено, и я уверен, что пропустил некоторые детали).

Таким образом, WebProject1.dll - это просто фактический C # / VB вашего веб-приложения, но в сочетании с рабочим процессом asp.net и разметкой, которую вы можете отобразить html обратно клиенту.

Answer 3

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

Я предлагаю вам использовать Отражатель , чтобы открыть DLL, и вы можете получить гораздо более глубокое понимание того, что находится внутри DLL.