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


848

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

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

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


6
Полное и более свежее (для 4.5) сравнение и объяснение можно найти здесь, на MSDN: Проекты веб-приложений и проекты веб-сайтов в Visual Studio
Густав,

Ответы:


556

Веб-сайт:

Проект веб-сайта компилируется на лету. В итоге вы получите гораздо больше 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.


5
Вы все еще можете скомпилировать весь ваш сайт в dll с помощью файлового веб-сайта.
ДТК

31
То, как я склонен думать об этом. Если вы программируете приложение, которое использует HTML в качестве пользовательского интерфейса, тогда используйте веб-приложение. Если у вас есть веб-сайт, который требует немного Asp.net, на нескольких его страницах используйте Web Site Project.
Ян Рингроз

35
На самом деле проекты веб-приложений были в точности исходным типом проекта ASP.NET. Они не похожи на проекты, которые были у нас в Visual Studio 2003. Они не были созданы как надстройка. Visual Studio 2005 SP1 просто восстановил то, что по ошибке удалил RTM Visual Studio 2005.
Джон Сондерс

1
Вы можете использовать вывод WebApplication в проекте WebDeployment. Вы не можете использовать вывод WebSite в проекте WebDeployment. Если вы хотите создать проект развертывания, придерживайтесь WebApplication. Но для разработки WebSite удобнее. Тем не менее, преобразование не всегда без проблем, поэтому начните с WebApplication прямо сейчас.
Стефан Штайгер

8
@xarzu: у "проектов" веб-сайта нет файла .csproj или .vbproj. На самом деле это не проекты, а папки с файлами.
Джон Сондерс

171

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

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

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

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


43
Поскольку программисты пишут приложение, оно создается. Команда тестирования тестирует приложение в тестовой системе. Затем клиент устанавливает приложения. Это последнее, что вы хотите, чтобы кто-то вносил живые изменения!
Ян Рингроз

12
Для меня выбор является лучшим, на сайтах вы всегда можете наследовать от скомпилированного базового класса, если хотите. Существует много языков / структур (например, PHP), где люди привыкли к идее развертывания исходного кода. Это не значит, что это не «серьезные» приложения.
Макс Торо

6
«На самом деле, вы не управляете этими DLL, [...] вам даже не нужно знать, что они существуют. Не проблема». - Пока инфраструктура не запутается, неправильно очищает старые версии и начинает выдавать исключения компиляции с конфликтующими именами по всему сайту ... Вы можете добавить обнаружение ошибок разметки с помощью проекта WebDeployment. Я также не уверен в вашем последнем замечании «с веб-сайтами, которые вы можете использовать IIS в качестве сервера», вы можете сделать это и с веб-приложением - и у меня есть такие проекты, где этот проект является частью более крупного веб-приложения.
Жаф - Бен Дугуид

3
Развертывание веб-сайта не всегда должно осуществляться на работающем сервере. В идеальном мире итерации разработки должны быть проверены на зеркале живой среды. Невозможность быстрых изменений кода в веб-приложениях на сайте, работающем на сервере IIS разработки (т.е. не работающем с использованием локального экземпляра VS), затрудняет тестирование быстрых небольших решений. Это происходит постоянно в системах, где вы не можете повторить одни и те же условия на локальном компьютере.
НикоРобертс

4
«Это может быть настоящей болью во время разработки, так как вам нужно продолжать сборку, чтобы увидеть изменения» ... имейте в виду, что это должен быть МАССОВЫЙ проект или ДЕЙСТВИТЕЛЬНО СТАРЫЙ компьютер, чтобы это было трудной задачей восстановление в эти дни.
Даррен

75

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

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

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

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

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


40

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

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

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


30

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

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

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


Я думаю, что ответ о том, должен ли я использовать кодовый файл или кодовый код в разметке, пропал с ответом, который был удален SO ...
frenchone

Так что для тех, кто интересуется: веб-приложение = хорошо структурированное решение = кодовая разметка в разметке VS веб-сайт = куча файлов = кодовый файл в разметке
frenchone

22

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

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

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

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

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


3
> Самым большим плюсом модели веб-сайта является то, что все в разделе app_code динамически компилируется. Это также имеет большой недостаток. Мой веб-сайт размещен на webhost4life, которые дешевы, но многофункциональны. Недостатком является то, что они очень часто перерабатывают рабочий процесс (15 минут?), Что означает, что у следующего пользователя очень медленный вывод первой страницы при перекомпиляции приложения.
Роб Николсон

19

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

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

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

№ 4 не так. «Изменить и продолжить» может быть включен, с некоторыми ограничениями. Возможно, это было правдой в 2011 году. № 9 должен сказать: «Вы не можете редактировать отдельные файлы исходного кода без перекомпиляции». Вы можете редактировать .aspx, .js, .css и т. Д. Без перекомпиляции.
Джон Сондерс

№ 4 имеет другой угол. Если вы откроете веб-сайт с помощью меню «Файл»> «Открыть»> «Веб-сайт» и перейдете в папку файловой системы для веб-сайта, вместо того , чтобы открывать сайт с помощью выбора решения в стартовом окне, вы можете редактировать модули классов и кодовую область (по крайней мере, в vb.net). ) без остановки отладки. Вы не увидите изменений, пока не перестроите, однако часто полезно иметь возможность наблюдать за поведением страницы во время изменения кода. Недостатком является то, что вы теряете все, что входит в решение: точки останова, открытые файлы, закладки и т. Д. И вам иногда приходится удалять файлы sln / sou.
путник

16

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

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

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


16

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


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

+1 за различия в codebehind (webapp) и codefile (website) в директиве страницы. Это точность, которой не хватает в выбранном ответе.
Французский

11

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

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

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

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

11

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

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


4
«Различие между этими двумя было устранено в vs2008» - не уверен, что вы там имеете в виду - они по-прежнему являются разными типами проектов в VS2008, ведут себя по-разному и создаются с помощью различных опций меню - однако, по крайней мере, они оба доступны по умолчанию в VS2008.
Жаф - Бен Дугуид

9

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

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


Это частично верно, вы можете предварительно скомпилировать страницы на сайте, если хотите
Amr H. Abd Elmajeed

8

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

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



7

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


5

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

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

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


1
Файл решения не обязательно должен находиться в одной папке. Кроме того, стандартный механизм публикации удаляет любые артефакты, которых не должно быть на целевом сайте, например, файлы с выделенным кодом не развертываются.
Джон Сондерс

5

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

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

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

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

5

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

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

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


4

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

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


2
-1 У вас действительно есть файл решения, если вы создаете проект веб-сайта с помощью Visual Studio. У вас нет файла проекта.
Даррен

+1 конечно, вы можете создать файл решения, но этот файл в основном пуст, так что это просто раздражение (VS спрашивает, где сохранить файл при выходе), а не что-то
полезное

3

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


3

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

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


«Компиляция полного проекта» не означает компиляцию каждого файла в проекте. Файлы исходного кода, которые не были изменены, не будут перекомпилированы.
Джон Сондерс

3

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


3

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


Вы также можете редактировать файл aspx в проекте веб-приложения.
Джон Сондерс

3

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

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

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


Это не похоже на исключение во время компиляции.
Джон Сондерс

1

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

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


Это не относится к asp.net. Различие между веб-сайтом и веб-приложением (в терминологии asp.net) заключается в том, как файлы организованы (как хорошо организованное решение или как группа файлов) и скомпилированы («JIT» против статического). В обоих случаях «программа» находится в основном на стороне сервера.
Французский

0

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

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

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

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

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

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

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

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.