Веб-сайт ASP.NET или веб-приложение ASP.NET?

Веб-сайт - это то, что вы развертываете на веб-сервере ASP.NET, таком как IIS. Просто куча файлов и папок. Нет ничего на веб-сайте, который связывает вас с Visual Studio (нет файла проекта). Генерация кода и компиляция веб-страниц (например,.aspx,.ascx,.master) выполняются динамически во время выполнения и изменения этих файлов обнаруживаются каркасом и автоматически перекомпилируются. Вы можете поместить код, который вы хотите делиться между страницами в специальной папке App_Code, или вы можете предварительно скомпилировать его и поместить сборку в корзину папку.

Веб-приложение - это специальный проект Visual Studio. Основное отличие веб-сайтов заключается в том, что при создании проекта все файлы кода скомпилированы в одну сборку, которая помещается в каталог bin. Вы не разворачиваете файлы кода на веб-сервер. Вместо того, чтобы иметь специальную папку для файлов общего кода, вы можете поместить их в любом месте, как и в библиотеке классов. Поскольку веб-приложения содержат файлы, которые не предназначены для развертывания, такие как файлы проекта и кода, theres Опубликовать команду в Visual Studio для вывода Web Сайт в указанное место.

App_Code vs Bin

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

CodeBehind

Этот раздел посвящен файлам .aspx и .ascx. Этот раздел становится все более актуальным в новых инфраструктурах приложений, таких как ASP.NET MVC и веб-страницы ASP.NET, которые не используют файлы codebehind.

Имея все файлы кода, скомпилированные в одну сборку, включая codebehind файлы .aspx-страниц и .ascx-элементов управления, в веб-приложениях, которые у вас есть перестроить для каждого небольшого изменения, и вы не можете вносить изменения в жизнь. Это может быть настоящей болью во время разработки, поскольку вы должны продолжать перестраивать, чтобы видеть изменения, в то время как изменения веб-сайтов обнаруживаются средой выполнения, а страницы/элементы управления автоматически перекомпилируются.

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

Я не говорю, что развертывание файлов кода всегда является хорошей идеей (особенно не для файлов с общим кодом), но файлы codebehind должны содержать только код, который выполняет специфические задачи пользовательского интерфейса, обработчики событий проводки и т.д. Ваше приложение должно быть слоистым, чтобы важный код всегда попадал в папку Bin. Если это так, то развертывание файлов codebehind не должно считаться вредным.

Другим ограничением веб-приложений является то, что вы можете использовать только язык проекта. На веб-сайтах вы можете иметь некоторые страницы на С#, некоторые в VB и т.д. Нет необходимости в специальной поддержке Visual Studio. Это красота расширяемости поставщика сборки.

Кроме того, в веб-приложениях вы не обнаружите обнаружение ошибок в страницах/элемента управления, поскольку компилятор компилирует только классы кода, а не код разметки (в MVC вы можете исправить это с помощью опции MvcBuildViews), которая компилируется во время выполнения.

Visual Studio

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

Еще одна приятная функция, представленная в Visual Studio 2010, - преобразование Web.config. Это также недоступно в веб-сайтах. Теперь работает с веб-сайтами в VS 2013.

Построение веб-приложения выполняется быстрее, чем создание веб-сайта, особенно для крупных сайтов. Это связано главным образом с тем, что веб-приложения не компилируют код разметки. В MVC, если вы установите MvcBuildViews в true, тогда он компилирует код разметки, и вы получаете обнаружение ошибок, что очень полезно. Нижняя сторона заключается в том, что каждый раз, когда вы строите решение, он строит полный сайт, который может быть медленным и неэффективным, особенно если вы не редактируете сайт. Я нахожу, что включаю и выключаю MvcBuildViews (что требует выгрузки проекта). С другой стороны, с помощью веб-сайтов вы можете выбрать, хотите ли вы построить сайт как часть решения или нет. Если вы решите не делать этого, то создание решения происходит очень быстро, и вы всегда можете щелкнуть по веб-сайту node и выбрать "Сборка", если вы внесли изменения.

В проекте MVC Web Application у вас есть дополнительные команды и диалоги для общих задач, такие как "Добавить вид", "Перейти к представлению", "Добавить контроллер" и т.д. Они недоступны на веб-сайте MVC.

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

Восстановление пакета NuGet не работает на веб-сайтах, вам необходимо вручную установить пакеты, перечисленные на packages.config. Восстановление пакетов теперь работает с веб-сайтами начиная с NuGet 2.7

Веб-сайт= использовать, когда веб-сайт создан графическими дизайнерами, а программисты редактируют только одну или две страницы

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

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

(Некоторые ошибки кодирования находятся в веб-приложениях во время компиляции, которые не встречаются на веб-сайтах до времени выполнения.)

Предупреждение: Я написал этот ответ много лет назад и не использовал Asp.net с тех пор. Я ожидаю, что теперь все изменится.

Если у вас нет конкретной потребности в динамически скомпилированном проекте, не используйте проект веб-сайта.

Почему? Поскольку проект веб-сайта приведет вас к стене, когда вы пытаетесь изменить или понять свой проект. Статические функции поиска текста (например, поиск, рефакторинг) в Visual Studio будут выполняться навсегда в любом проекте с разумным размером. Для получения дополнительной информации см. Вопрос "Переполнение стека" Медленно "Найти все ссылки" в Visual Studio.

Я действительно не понимаю, почему они бросили веб-приложения в Visual Studio 2005 для создающего боль, безумного дренажа, производительности проекта веб-сайта carbuncle.

В MSDN есть статья, которая описывает различия:

Сравнение проектов веб-сайтов и проектов веб-приложений

Кстати: есть несколько похожих вопросов по этой теме, например:

• Веб-сайт и веб-приложение ASP.Net в Visual Studio примечание: было удалено, больше не на SO
• веб-сайт или веб-приложение in.ASP.NET

Это может показаться немного очевидным, но я думаю, что это неправильно понято, потому что Visual Studio 2005 только первоначально отправляется на веб-сайт. Если ваш проект имеет дело с сайтом, который является довольно ограниченным и не имеет большого логического или физического разделения, веб-сайт в порядке. Однако, если это действительно веб-приложение с различными модулями, где многие пользователи добавляют и обновляют данные, вам лучше работать с веб-приложением.

Самый большой профи модели веб-сайта заключается в том, что все в разделе app_code динамически компилируется. Вы можете делать обновления файлов С# без полного перераспределения. Однако это приносит огромную жертву. Много вещей происходит под крышками, которые трудно контролировать. Пространства имен трудно контролировать, а использование определенных DLL файлов по умолчанию выходит за окно под app_code, поскольку все динамически компилируется.

Модель веб-приложения не имеет динамической компиляции, но вы получаете контроль над вещами, о которых я упоминал.

Если вы занимаетесь разработкой n-уровневого уровня, я настоятельно рекомендую модель веб-приложения. Если вы делаете ограниченный веб-сайт или быстро и грязно, модель веб-сайта может иметь преимущества.

Более подробный анализ можно найти в:

• Проекты веб-приложений и проекты веб-развертывания здесь
• Веб-сайт или веб-приложение

Из экзамена 70-515 экзаменационного экзамена MCTS для самостоятельного курса:

С веб-приложением (проектом),

• Вы можете создать приложение MVC.
• Visual Studio хранит список файлов в файле проекта (.csproj или .vbproj), а не полагается на структуру папок.
• Вы не можете смешивать Visual Basic и С#.
• Вы не можете редактировать код, не останавливая сеанс отладки.
• Вы можете установить зависимости между несколькими веб-проектами.
• Вы должны скомпилировать приложение перед развертыванием, что не позволяет вам тестировать страницу, если другая страница не будет компилироваться.
• Вам не нужно хранить исходный код на сервере.
• Вы можете управлять именем и версией сборки.
• Вы не можете редактировать отдельные файлы после развертывания без повторной компиляции.

Compilation Во-первых, разница в компиляции. Веб-сайт не предварительно скомпилирован на сервере, он скомпилирован в файл. Это может быть преимущество, потому что, когда вы хотите что-то изменить в своей сети На сайте вы можете просто загрузить определенный файл с сервера, изменить его и загрузите этот файл на сервер, и все будет работать нормально. В Интернете Приложение вы не можете сделать это, потому что все когда-либо предварительно скомпилировано и вы получаете только одну DLL. Когда вы меняете что-то в одном файле ваш проект, вам нужно снова скомпилировать все. Так что если бы вы например, иметь возможность изменять некоторые файлы на веб-сайте сервера лучшее решение для вас. Он также позволяет многим разработчикам работать на одном Веб-сайт. С другой стороны, если вы не хотите, чтобы ваш код был доступный на сервере, вы должны выбрать Web Application. Эта вариант также лучше подходит для модульного тестирования из-за того, что один DLL файл является созданный после публикации вашего веб-сайта.

Project structure  Существует также различие в структуре проекта. В веб-приложении у вас есть файл проекта, как и в обычном приложении. На веб-сайте нет традиционного файла проекта, все, что у вас есть, - это файл решения. Все ссылки и настройки хранятся в файле web.config. @Page directive  В директиве @Page есть другой атрибут для файла, который содержит класс, связанный с этой страницей. В веб-приложении он является стандартным "CodeBehind", на веб-сайте используется "CodeFile". Вы можете увидеть это в следующих примерах:

Web Application:

<%@ Page Language="C#" AutoEventWireup="true" CodeBehind="Default.aspx.cs"  
Inherits="WebApplication._Default" %>  

Веб-сайт:

<%@ Page Language="C#" AutoEventWireup="true" CodeFile="Default.aspx.cs" Inherits="_Default" %> 

Пространства имен. В приведенном выше примере вы можете увидеть и другое различие - как создаются пространства имен. В пространстве имен веб-приложений просто название проекта. На веб-сайте существует пространство имен по умолчанию для ASP динамически скомпилированные страницы.

Изменить и продолжить. В параметре "Редактирование и продолжение веб-приложения" (чтобы включить его, вам нужно перейти в меню "Сервис", нажмите "Параметры" затем найдите "Редактировать" и "Продолжить в отладке" ). Эта функция не работает в Web Site.ASP.NET MVCIf вы хотите разработать веб-приложения, используя

ASP.NET MVC (Model View Controller) - лучшая и стандартная опция - Веб приложение. Хотя можно использовать MVC на веб-сайте, это не рекомендуется.

Резюме. Самое важное различие между веб-приложением ASP.NET и веб-сайт - это компиляция. Поэтому, если вы работаете над большим проектом, несколько человек могут изменить его, чтобы лучше использовать веб-сайт. Но если вы делая меньший проект, вы также можете использовать веб-приложение.

Это зависит от того, что вы разрабатываете.

Веб-сайт, ориентированный на контент, будет часто меняться, и сайт лучше для этого.

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

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

Различие между ними было устранено в Visual Studio 2008.

Да, веб-приложение намного лучше, чем веб-сайты, потому что веб-приложения дают нам свободу:

• Чтобы иметь несколько проектов под одним зонтиком и создать проект зависимости между ними. Например. для PCS мы можем иметь в сети приложение -

  • Веб-порталы
  • Контроллер уведомлений (для отправки электронной почты)
  • Бизнес-уровень
  • Уровень доступа к данным
  • Менеджер исключений
  • Утилита сервера
  • Услуги WCF (общие для всех платформ)
  • Элемент списка

• Для запуска модульных тестов кода, который находится в файлах классов, которые связанные с страницами ASP.NET

• Для обозначения классов, которые являются связанные со страницами и пользовательскими элементами управления из автономных классов
• Чтобы создать единую сборку для всего сайта
• Управление именем сборки и номером версии, созданной для сайта
• Чтобы избежать размещения исходного кода на рабочем сервере. (Вы можете избежать развертывание исходного кода на сервере IIS. В некоторых сценариях, таких как вы можете быть обеспокоены несанкционированный доступ к исходному коду на сервере IIS. (Для Интернета сайта, вы можете избежать этого риска, предварительно скомпилировав компьютер разработки и развертывание сгенерированных сборок вместо исходного кода. Однако в этом случае вы теряете часть преимущества простых обновлений сайта.)
• Ошибка производительности с веб-сайта первый запрос на веб-сайт может потребовать, чтобы сайт был скомпилирован, что может привести к задержке. И если веб-сайт работает на IIS, который не хватает памяти, включая весь сайт в единая сборка может использовать больше памяти, чем требуется для несколько сборок.)

Приложения обычно скомпилируются перед развертыванием, когда сайт использует каталог app_code. Когда что-либо изменяется в папке с кодом приложения, сервер будет перекомпилировать код. Это означает, что вы можете добавлять/изменять код с веб-сайта на лету.

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

"Веб-сайт" имеет свой код в специальном каталоге App_Code и скомпилирован в несколько DLL (сборок) во время выполнения. "Веб-приложение" предварительно скомпилировано в одну DLL.

Я рекомендую вам посмотреть видео Проекты веб-приложений и проекты веб-развертывания на веб-сайте ASP.NET, в котором объясняется различие в деталях, это был мне очень полезен.

Кстати, не путайте название, большая часть видео объясняет разницу между проектами веб-сайтов и проектами веб-приложений и почему Microsoft повторно представила проекты веб-приложений в Visual Studio 2005 (как вы, вероятно, уже знаете, он первоначально был отправлен только с веб-проектами, тогда в SP1 были добавлены проекты веб-приложений). Отличное видео, которое я рекомендую всем, кто хочет узнать разницу.

Модель проекта веб-приложения

• Предоставляет семантику того же Web-проекта, что и Visual Studio.NET Web проекты. Имеет файл проекта (структура, основанная на файлах проекта). Build model - весь код в проекте скомпилирован в один сборка. Поддерживает как IIS, так и встроенную ASP.NET Development Сервер. Поддерживает все функции Visual Studio 2005 (рефакторинг, дженерики и т.д.) и ASP.NET(мастер-страницы, членство и логин, навигации по сайту, тем и т.д.). Использование серверных расширений FrontPage (FPSE) больше не являются обязательными.

Модель проекта веб-сайта

• Нет файла проекта (на основе файловой системы).
• новый сборник модель.
• Динамическая компиляция и работа на страницах без создания всего сайта на каждом просмотре страницы.
• Поддерживает как IIS, так и встроенный сервер разработки ASP.NET.
• Каждая страница имеет свою собственную сборку.
• Модель кода Defferent.

Это всегда зависит от требований вашего клиента. ASP.NET включает в себя гибкие функции, необходимые пользователю для обеспечения безопасности и простого обслуживания вашего приложения.

Вы можете думать о веб-приложении как двоичном файле, который выполняется внутри рамки ASP.NET. И Веб-сайты в качестве статической веб-страницы, которую вы можете просмотреть и легко развернуть исходный код.

Но преимущество и недостатки этих двух технологий ASP.NET - это то, что хорошо.

Веб-сайт и проект → веб-сайт - это два разных метода создания приложения ASP.NET с использованием visual studio. Один из них безпроектирован, а другой - это среда проекта. Различия:

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

нет принципиальной разницы в использовании любого подхода. Но если вы создаете веб-сайт, который займет больше времени, выберите среду проекта.

Веб-сайты. Файл решения не будет создан. Если мы хотим создавать веб-сайты, вам не нужна визуальная студия.

Веб-приложение. Будет создан файл решения. Если мы хотим создать веб-приложение, вам нужна визуальная студия. Он создаст единственный файл .dll в папке bin.

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

Веб-приложения требуют больше памяти, по-видимому, потому, что у вас нет выбора, кроме как скомпилировать в одну сборку. Я просто превратил большой старый сайт в веб-приложение и имею проблемы с нехваткой памяти, как во время компиляции с помощью

Unexpected error writing metadata to file '' -- 
Not enough storage is available to complete this operation. 

и во время выполнения с этой ошибкой:

Exception information: 
    Exception type: HttpException 
    Exception message: Exception of type 'System.OutOfMemoryException' was thrown.
   at System.Web.Compilation.BuildManager.ReportTopLevelCompilationException()

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

WebSite: Он автоматически создает папку app_code и публикует его на сервере, а после этого, если вы делаете некоторые изменения в любом конкретном файле или странице, вам не нужно компилировать все файлы.

Веб-приложение Он автоматически генерирует файл решений, который не создается на веб-сайте, и если вы меняете в одном файле, вы должны скомпилировать полный проект, чтобы отобразить его изменения.

Определенно веб-приложение, один DLL файл и прост в обслуживании. Но сайт более гибкий; вы можете редактировать файл aspx на ходу.

В проектах веб-приложений Visual Studio нуждается в дополнительных файлах .designer для страниц и пользовательских элементов управления. Проекты веб-сайта не требуют этих накладных расходов. Сама разметка интерпретируется как дизайн.

Здесь Web Supportive Application - пример веб-сайта. Веб-сайт и веб-приложение могут быть динамическими/статичными, что зависит от требований, вот пример, чтобы понять работу веб-сайта и веб-приложения.

Чтобы обобщить некоторые из приведенных выше ответов:

Гибкость. Можете ли вы сделать живые изменения на веб-странице?

Веб-сайт: возможно. Pro: краткосрочные выгоды. Con: долгосрочный риск проектного хаоса.

Веб-приложение: Con: невозможно. Отредактируйте страницу, запишите изменения в исходный элемент управления, затем создайте и разверните весь сайт. Pro: поддерживать качественный проект.

Проблемы развития

Веб-сайт: простая структура проекта без файла .csproj. Две страницы .aspx могут иметь одно и то же имя класса без конфликтов. Случайное имя каталога проекта, которое приводит к ошибкам сборки, например почему .net-инфраструктура конфликтует с собственным созданным файлом и почему .net framework конфликтует с собственный файл. Pro: Простой (упрощенный). Con: неустойчивый.

Веб-приложение: структура проекта похожа на проект WebForms с файлом .csproj. Названия классов asp-страниц должны быть уникальными. Pro: Простой (умный). Con: none, потому что веб-приложение все еще просто.