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

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

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

App_Code vs Bin

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

CodeBehind

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

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

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

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

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

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

визуальный Студия

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

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

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

в проекте веб-приложения MVC у вас есть дополнительные команды и диалоги для общих задач, таких как "добавить представление", "перейти к просмотру", "добавить контроллер" и т. д. Они недоступны в Интернете MVC Сайт.

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

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

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

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

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

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

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

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

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

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

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

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

BTW: есть некоторые аналогичные вопросы по этой теме, e.g:

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

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

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

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

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

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

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

из MCTS self paced training kit экзамен 70-515 книга:

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

1. вы можете создать приложение MVC.
2. в Visual Studio хранит список файлов в файл проекта (.csproj или .vbproj), а не полагаться на структуру папок.
3. нельзя смешивать Visual Basic и C#.
4. вы не можете редактировать код без остановки сеанса отладки.
5. вы можете установите зависимости между несколькими веб-проектами.
6. вы должны скомпилировать приложение перед развертыванием, что предотвращает тестирование страницы, если другая страница не будет скомпилирована.
7. вам не нужно хранить исходный код на сервере.
8. вы можете управлять именем и версией сборки.
9. вы не можете редактировать отдельные файлы после развертывания без перекомпиляции.

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

Project structure Существует также различие в структуре проекта. В веб-приложении у вас есть файл проекта, как и в обычном приложении. На веб-сайте нет традиционного файла проекта, все, что у вас есть, это файл решения. Все ссылки и настройки хранятся в интернете.конфигурационный файл. @Page directive В директиве @Page для файла, содержащего класс, связанный с этой страницей, существует другой атрибут. в web Приложение является стандартным "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 по умолчанию для динамически скомпилированные страницы.

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

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

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

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

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

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

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

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

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

1. иметь несколько проектов под одним зонтиком и создать проект зависимости между. Е. Г. для ПК у нас может быть следующим в веб применение -

   • веб-порталов
   • контроллер уведомлений (для отправки электронной почты)
   • бизнес-уровня
   • уровень доступа к данным
   • исключение Менеджер!--8-->
   • утилиты сервера
   • службы WCF (общие для всех платформ)
   • элемент списка

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

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

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

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

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

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

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

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

1. файл решения хранится в том же каталоге, что и корневой каталог в среде проекта.
2. перед развертыванием в среде проекта необходимо удалить файлы решений и проектов.
3. полный корневой каталог развернут в projectless окружающая среда.

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

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

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

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

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

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

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

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

Websites - файл решения не будет создан. Если мы хотим создать веб-сайты, нет необходимости в visual studio.

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

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

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

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

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

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

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

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()

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

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

чтобы суммировать некоторые из ответов выше:

гибкость вы можете вносить изменения на веб-страницу?

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

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

развитие вопросы

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

Веб-Приложение структура проекта аналогична Проект WebForms, с a .файл csproj. Имена классов страниц asp должны быть уникальными. Плюсы: Простой (смарт). Con: нет, потому что веб-приложение по-прежнему просто.