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

Web Site это то, что вы развертываете в ASP.NET веб-сервер, например IIS. Просто куча файлов и папок. На веб-сайте нет ничего, что связывает вас с Visual Studio (нет файла проекта). Генерация кода и компиляция веб-страниц (например .aspx, .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, в Интернете Приложения, которые вы должны перестроить для каждого небольшого изменения, и вы не можете сделать живые изменения. Это может быть настоящей болью во время разработки, так как вы должны продолжать перестраивать, чтобы увидеть изменения, в то время как с веб-сайтами изменения обнаруживаются во время выполнения и страницы/элементы управления автоматически перекомпилируются.

Если среда выполнения управляет сборками 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, то он компилирует код разметки, и вы получаете обнаружение ошибок, что очень полезно. Недостатком является то, что каждый раз, когда вы создаете решение, он создает полный сайт, который может быть медленным и неэффективным, особенно если вы не редактируете сайт. я обнаружил, что включаю и выключаю MvcBuildViews (что требует проект выгрузить). С другой стороны, с помощью веб-сайтов вы можете выбрать, хотите ли вы создать сайт как часть решения или нет. Если вы решите этого не делать, то построение решения будет очень быстрым, и вы всегда можете нажать на узел веб-сайта и выбрать построить, если вы внесли изменения.

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

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

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

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

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

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

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

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

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

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

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

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

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

кстати: есть некоторые подобные вопросы по этой теме, например:

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

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

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

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

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

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

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

из MCTS self paced training kit exam 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" %> 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

веб-приложение-будет создан файл решения. Если мы хотим создать веб-приложение должно понадобиться 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: невозможно. Отредактируйте страницу, архивируйте изменения в системе управления версиями, а затем создайте и разверните весь сайт. Pro: поддерживать качественный проект.

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

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

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