Веб-сайт - это то, что вы развертываете на веб-сервере ASP.NET, таком как IIS. Просто куча файлов и папок. На веб-сайте нет ничего, что связывало бы вас с Visual Studio (нет файла проекта). Генерация кода и компиляция веб-страниц (таких как .aspx, .ascx, .master) выполняется динамически во время выполнения , и изменения в этих файлах обнаруживаются платформой и автоматически перекомпилируются. Вы можете поместить код, который вы хотите поделиться на страницах , в специальную папку App_Code, или вы можете предварительно скомпилировать его и поместить сборку в папку Bin.
Веб-приложение - это специальный проект Visual Studio. Основное отличие веб-сайтов состоит в том, что при сборке проекта все файлы кода компилируются в одну сборку, которая помещается в каталог bin. Вы не развертываете файлы кода на веб-сервере. Вместо специальной папки для файлов с общим кодом вы можете поместить их в любое место, как в библиотеке классов. Поскольку веб-приложения содержат файлы, которые не предназначены для развертывания, такие как файлы проекта и кода, в Visual Studio есть команда Опубликовать для вывода веб-сайта в указанное место.
App_Code vs Bin
Развертывание файлов с общим кодом, как правило, плохая идея, но это не значит, что вам нужно выбирать веб-приложение. У вас может быть веб-сайт, который ссылается на проект библиотеки классов, в котором содержится весь код веб-сайта. Веб-приложения - это просто удобный способ сделать это.
CodeBehind
Этот раздел относится к файлам .aspx и .ascx. Этот раздел становится все менее актуальным в новых инфраструктурах приложений, таких как ASP.NET MVC и ASP.NET Web Pages, которые не используют файлы с выделенным кодом.
Скомпилировав все файлы кода в одну сборку, включая codebehind файлов страниц .aspx и элементов управления .ascx, в веб-приложениях вам придется пересобирать каждое небольшое изменение, и вы не можете сделать живые изменения. Во время разработки это может быть серьезной болью, так как вам нужно продолжать сборку, чтобы увидеть изменения, в то время как с веб-сайтами изменения обнаруживаются средой выполнения, а страницы / элементы управления автоматически перекомпилируются.
Наличие среды выполнения для управления сборками кода является для вас меньшей работой, поскольку вам не нужно беспокоиться о том, чтобы присваивать страницам / элементам управления уникальные имена или организовывать их в разные пространства имен.
Я не говорю, что развертывание файлов кода - это всегда хорошая идея (особенно не в случае файлов с общим кодом), но файлы со связанными кодами должны содержать только код, который выполняет специфические для пользовательского интерфейса задачи, обработчики событий подключения и т. Д. приложение должно быть многоуровневым, чтобы важный код всегда попадал в папку Bin. Если это так, то развертывание кодовых файлов не должно считаться вредным.
Еще одним ограничением веб-приложений является то, что вы можете использовать только язык проекта. На веб-сайтах вы можете иметь несколько страниц на C #, некоторые на VB и т. Д. Нет необходимости в специальной поддержке Visual Studio. В этом прелесть расширяемости поставщика сборки.
Кроме того, в веб-приложениях вы не обнаруживаете ошибки в страницах / элементах управления, поскольку компилятор компилирует только ваши классы codebehind, а не код разметки (в MVC это можно исправить с помощью параметра MvcBuildViews), который компилируется во время выполнения .
Visual Studio
Поскольку веб-приложения являются проектами Visual Studio, вы получаете некоторые функции, недоступные на веб-сайтах. Например, вы можете использовать события сборки для выполнения различных задач, например, минимизировать и / или объединять файлы Javascript.
Еще одна приятная функция, представленная в Visual Studio 2010, - это Преобразование Web.config . Это также недоступно на веб-сайтах. Теперь работает с веб-сайтами в VS 2013.
Строительствовеб-приложение быстрее, чем создание веб-сайта, особенно для больших сайтов. Это главным образом потому, что веб-приложения не компилируют код разметки. В MVC, если вы устанавливаете MvcBuildViews в true, он компилирует код разметки, и вы получаете обнаружение ошибок, что очень полезно. Недостатком является то, что каждый раз, когда вы создаете решение, оно создает полный сайт, который может быть медленным и неэффективным, особенно если вы не редактируете сайт. Я обнаружил, что включаю и выключаю MvcBuildViews (что требует разгрузки проекта). С другой стороны, с помощью веб-сайтов вы можете выбрать, хотите ли вы создать сайт как часть решения или нет. Если вы решите не делать этого, то создание решения будет очень быстрым, и вы всегда можете щелкнуть по узлу веб-сайта и выбрать «Построить», если вы внесли изменения.
В проекте веб-приложения MVC у вас есть дополнительные команды и диалоги для общих задач, таких как «Добавить представление», «Перейти к просмотру», «Добавить контроллер» и т. Д. Они недоступны на веб-сайте MVC.
Если вы используете IIS Express в качестве сервера разработки, на веб-сайтах вы можете добавлять виртуальные каталоги. Этот параметр недоступен в веб-приложениях.
Восстановление пакетов NuGet не работает на веб-сайтах, вам необходимо вручную устанавливать пакеты, перечисленные в packages.config Восстановление пакетов теперь работает с веб-сайтами , начиная с NuGet 2.7