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

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

В чем разница между веб-приложением ASP.NET и веб-сайтом ASP.NET? Почему я бы выбрал одно над другим?

Отличается ли ответ в зависимости от того, какую версию Visual Studio я использую?

29.12.2008 16:24:13
Полное и более свежее (для 4.5) сравнение и объяснение можно найти здесь, в MSDN: Проекты веб-приложений и проекты веб-сайтов в Visual Studio
Gustav 18.11.2016 11:58:19
25 ОТВЕТОВ
РЕШЕНИЕ

Веб-сайт:

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

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

Веб приложение:

Проект веб-приложения был создан как надстройка и теперь существует как часть пакета обновления 1 для Visual Studio 2005. Основными отличиями является проект веб-приложения, разработанный для работы аналогично веб-проектам, поставляемым с Visual Studio 2003. Он будет скомпилировать приложение в один файл DLL во время сборки. Для обновления проекта его необходимо перекомпилировать и опубликовать файл DLL, чтобы изменения произошли.

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

Ссылка

В статье ASP.NET 2.0 - Проект «Веб-сайт против веб-приложения» также приведены причины, по которым следует использовать один, а не другой. Вот выдержка из этого:

  • Вам нужно перенести большие приложения Visual Studio .NET 2003 на VS 2005? используйте проект веб-приложения.
  • Вы хотите открывать и редактировать любой каталог как веб-проект, не создавая файл проекта? использовать веб-сайт проекта.
  • Вам нужно добавить шаги до и после сборки во время компиляции? использовать проект веб-приложения.
  • Вам нужно создать веб-приложение, используя несколько веб-проектов? использовать проект веб-приложения.
  • Вы хотите создать одну сборку для каждой страницы? использовать веб-сайт проекта.
  • Вы предпочитаете динамическую компиляцию и работу над страницами без построения всего сайта при каждом просмотре страницы? использовать веб-сайт проекта.
  • Вы предпочитаете одностраничную модель кода модели с выделенным кодом? использовать веб-сайт проекта.

Проекты веб-приложений и проекты веб-сайтов (MSDN) объясняют различия между веб-сайтом и проектами веб-приложений. Также здесь обсуждается конфигурация, которая будет выполнена в Visual Studio.

555
24.01.2020 04:28:05
Вы все еще можете скомпилировать весь ваш сайт в dll с помощью файлового веб-сайта.
dtc 31.12.2008 22:48:16
То, как я склонен думать об этом. Если вы программируете приложение, которое использует HTML в качестве пользовательского интерфейса, используйте Web Application. Если у вас есть веб-сайт, который нуждается в небольшом количестве Asp.net, на нескольких его страницах используйте Web Site Project.
Ian Ringrose 26.06.2009 11:17:19
Фактически, проекты веб-приложений были в точности исходным типом проекта ASP.NET. Они не похожи на проекты, которые были у нас в Visual Studio 2003. Они не были созданы как надстройка. Visual Studio 2005 SP1 просто восстановил то, что по ошибке удалил RTM Visual Studio 2005.
John Saunders 30.06.2009 02:09:44
Вы можете использовать вывод WebApplication в проекте WebDeployment. Вы не можете использовать вывод WebSite в проекте WebDeployment. Если вы хотите создать проект развертывания, придерживайтесь WebApplication. Но для разработки WebSite удобнее. Тем не менее, преобразование не всегда без проблем, поэтому начните с WebApplication прямо сейчас.
Stefan Steiger 7.08.2010 07:49:57
@xarzu: у "проектов" веб-сайта нет файла .csproj или .vbproj. На самом деле это не проекты, а папки с файлами.
John Saunders 12.12.2013 12:43:04

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

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

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

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

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

22
10.12.2011 16:47:26
> Самым большим плюсом модели веб-сайта является то, что все в разделе app_code динамически компилируется. Это также имеет большой недостаток. Мой веб-сайт размещен на webhost4life, которые дешевы, но многофункциональны. Недостатком является то, что они очень часто перезагружают рабочий процесс (15 минут?), Что означает, что у следующего пользователя очень медленный вывод первой страницы при перекомпиляции приложения.
Rob Nicholson 21.08.2009 12:42:44

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

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

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

30
29.03.2020 13:34:39
Я думаю, что ответ о том, должен ли я использовать кодовый файл или кодовый код в разметке, пропал с ответом, который был удален SO ...
frenchone 16.04.2018 15:41:44
Так что для тех, кто интересуется: веб-приложение = хорошо структурированное решение = кодовая разметка в разметке VS веб-сайт = куча файлов = кодовый файл в разметке
frenchone 16.04.2018 15:44:18

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

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

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

16
26.03.2015 14:35:28

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

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

11
26.03.2015 14:34:40
«Различие между этими двумя было устранено в vs2008» - не уверен, что вы там имеете в виду - они по-прежнему являются разными типами проектов в VS2008, ведут себя по-разному и создаются с помощью различных опций меню - однако по крайней мере они оба доступны по умолчанию в VS2008.
Zhaph - Ben Duguid 24.01.2009 14:24:41

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

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

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

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

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

75
19.08.2015 09:00:22

Веб-сайт - это то, что вы развертываете на веб-сервере 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 управления, в веб - приложениях , вы должны заново строить для каждого небольшого изменения, и вы не можете сделать живые изменения. Это может быть настоящей болью во время разработки, так как вам нужно продолжать перестройку, чтобы увидеть изменения, в то время как с веб-сайтами изменения обнаруживаются средой выполнения, а страницы / элементы управления автоматически перекомпилируются.

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

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

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

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

Visual Studio

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

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

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

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

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

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

171
7.06.2014 03:41:55
Поскольку программисты пишут приложение, оно создается. Команда тестирования тестирует приложение в тестовой системе. Затем клиент устанавливает приложения. Это последнее, что вы хотите, чтобы кто-то вносил живые изменения!
Ian Ringrose 23.06.2009 21:43:14
Для меня выбор является лучшим, на сайтах вы всегда можете наследовать от скомпилированного базового класса, если хотите. Существует много языков / структур (например, PHP), где люди привыкли к идее развертывания исходного кода. Это не значит, что это не «серьезные» приложения.
Max Toro 25.08.2009 20:29:05
«На самом деле, вы не управляете этими DLL, [...] вам даже не нужно знать, что они существуют. Не проблема». - Пока инфраструктура не запутается, неправильно очищает старые версии и начинает выдавать исключения компиляции с конфликтующими именами по всему сайту ... Вы можете добавить обнаружение ошибок разметки с помощью проекта WebDeployment. Я также не уверен в вашем последнем замечании «с веб-сайтами, которые вы можете использовать IIS в качестве сервера», вы можете сделать это и с веб-приложением - и у меня есть такие проекты, где проект является частью более крупного веб-приложения.
Zhaph - Ben Duguid 24.10.2009 19:49:23
Развертывание веб-сайта не всегда должно осуществляться на работающем сервере. В идеальном мире итерации разработки должны быть проверены на зеркале живой среды. Невозможность быстрых изменений кода в веб-приложениях на сайте, работающем на сервере IIS разработки (т.е. не работающем с локальным экземпляром VS), затрудняет тестирование небольших быстрых решений. Это происходит постоянно в системах, где вы не можете повторить одни и те же условия на локальном компьютере.
NikoRoberts 1.06.2011 18:37:50
«Это может быть настоящей болью во время разработки, так как вам нужно продолжать сборку, чтобы увидеть изменения» ... имейте в виду, что это должен быть МАССОВЫЙ проект или ДЕЙСТВИТЕЛЬНО СТАРЫЙ компьютер, чтобы это было трудной задачей восстановление в эти дни.
Darren 3.03.2014 05:02:06

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

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

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

40
23.05.2017 12:03:04

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

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

9
10.03.2015 20:43:16
Это частично верно, вы можете предварительно скомпилировать страницы на сайте, если хотите
Amr H. Abd Elmajeed 23.12.2010 11:47:03

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

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

8
10.12.2011 17:01:30
Видео сейчас находится по адресу: asp.net/web-forms/videos/vs-2005/…
Bob Reynolds 25.12.2015 20:52:58

Из экзаменационной программы MCTS 70-515:

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

  1. Вы можете создать приложение MVC.
  2. Visual Studio хранит список файлов в файле проекта (.csproj или .vbproj), а не полагается на структуру папок.
  3. Вы не можете смешивать Visual Basic и C #.
  4. Вы не можете редактировать код без остановки сеанса отладки.
  5. Вы можете установить зависимости между несколькими веб-проектами.
  6. Вы должны скомпилировать приложение перед развертыванием, что не позволяет вам тестировать страницу, если другая страница не будет компилироваться.
  7. Вам не нужно хранить исходный код на сервере.
  8. Вы можете контролировать имя сборки и версию.
  9. Вы не можете редактировать отдельные файлы после развертывания без перекомпиляции.
19
29.09.2014 12:58:33
№ 4 не так. «Редактировать и продолжить» можно включить с некоторыми ограничениями. Возможно, это было правдой в 2011 году. № 9 должен сказать: «Вы не можете редактировать отдельные файлы исходного кода без перекомпиляции». Вы можете редактировать .aspx, .js, .css и т. Д. Без перекомпиляции.
John Saunders 10.03.2015 20:33:23
№ 4 имеет другой угол. Если вы откроете веб-сайт с помощью меню «Файл»> «Открыть»> «Веб-сайт» и перейдете в папку файловой системы для веб-сайта, вместо того чтобы открывать сайт с помощью выбора решения в стартовом окне, вы можете редактировать модули классов и кодовую область (по крайней мере в vb.net) ) без остановки отладки. Вы не увидите изменений, пока не перестроите, однако часто полезно иметь возможность наблюдать за поведением страницы во время изменения кода. Недостатком является то, что вы теряете все, что входит в решение: точки останова, открытые файлы, закладки и т. Д. И вам иногда приходится удалять файлы sln / sou.
wayfarer 10.03.2015 23:16:21

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

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

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

5
31.08.2012 14:35:53
Файл решения не обязательно должен находиться в одной папке. Кроме того, стандартный механизм публикации удаляет любые артефакты, которых не должно быть на целевом сайте, например, файлы с выделенным кодом не развертываются.
John Saunders 31.08.2012 14:36:33

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

7
18.06.2012 07:44:11

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

3
4.07.2012 18:46:48

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

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

Но преимущества и недостатки этих двух технологий ASP.NET приходят на пользу.

5
26.03.2015 14:32:06

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

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

4
10.03.2015 20:39:16
-1 У вас действительно есть файл решения, если вы создаете проект веб-сайта с помощью Visual Studio. У вас нет файла проекта.
Darren 3.03.2014 04:51:41
+1 конечно, вы можете создать файл решения, но этот файл в основном пуст, так что это просто раздражение (VS спрашивает, где сохранить файл при выходе), а не что-то
frenchone 16.04.2018 15:55:08

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

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

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

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

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

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

Веб приложение:

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

Веб-сайт:

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

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

Редактировать и продолжить - в веб-приложении доступна опция «Редактировать и продолжить» (чтобы включить ее, нужно перейти в меню «Инструменты», нажать «Параметры», затем найти «Редактировать и продолжить в отладке»). Эта функция не работает на веб-сайте. ASP.NET MVC, если вы хотите разрабатывать веб-приложения, используя

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

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

16
21.10.2018 11:45:25
В большом проекте, где его изменяют несколько человек, вы используете систему контроля версий, поэтому это не является причиной для использования «проектов» веб-сайта.
John Saunders 10.03.2015 20:37:44
+1 за различие в codebehind (веб-приложение) и codefile (веб-сайт) в директиве страницы. Это точность, которой не хватает в выбранном ответе.
frenchone 16.04.2018 15:57:36

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

3
26.03.2015 14:29:07
Вы также можете редактировать файл aspx в проекте веб-приложения.
John Saunders 10.03.2015 20:38:08

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

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

    • Веб-порталы
    • Контроллер уведомлений (для отправки электронной почты)
    • Бизнес уровень
    • Уровень доступа к данным
    • Менеджер исключений
    • Серверная утилита
    • Услуги WCF (общие для всех платформ)
    • Пункт списка
  2. Чтобы запустить модульные тесты для кода, который находится в файлах классов, связанных со страницами ASP.NET

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

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

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

3
2.01.2014 05:10:45
«Компиляция полного проекта» не означает компиляцию каждого файла в проекте. Файлы исходного кода, которые не были изменены, не будут перекомпилированы.
John Saunders 10.03.2015 20:36:21

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

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

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

3
19.08.2018 18:50:12
Это не похоже на исключение во время компиляции.
John Saunders 10.03.2015 20:34:10

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

3
26.03.2015 14:28:02

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

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

1
6.01.2016 12:26:27
Это не относится к asp.net. Различие между веб-сайтом и веб-приложением (в терминологии asp.net) больше связано с тем, как файлы организованы (как хорошо организованное решение или как группа файлов) и скомпилированы («JIT» против статического). В обоих случаях «программа» находится в основном на стороне сервера.
frenchone 16.04.2018 15:27:06

Подводя итог некоторым ответам выше:

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

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

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

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

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

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

0
12.02.2018 12:38:19