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

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

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

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

+818
29 дек. '09 в 16:24
источник поделиться
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.

+537
29 дек. '09 в 16:28
источник

Связанные вопросы


Похожие вопросы

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

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

App_Code vs Bin

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

CodeBehind

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

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

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

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

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

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

Visual Studio

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

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

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

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

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

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

+164
09 мар. '09 в 19:16
источник

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

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

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

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

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

+73
04 мар. '09 в 14:19
источник

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

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

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

+39
15 июл. '09 в 20:15
источник

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

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

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

+29
24 янв. '09 в 12:16
источник

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

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

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

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

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

+20
29 дек. '09 в 17:23
источник

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

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

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

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

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

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

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

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

+16
03 янв. '13 в 13:52
источник

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

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

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

+14
24 янв. '09 в 12:17
источник

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

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

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

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

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

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

+11
24 янв. '09 в 12:19
источник

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

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

+9
15 авг. '09 в 17:03
источник

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

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

+8
28 сент. '09 в 12:21
источник

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

+7
18 июн. '12 в 7:44
источник

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

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

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

+5
05 июл. '12 в 3:26
источник

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

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

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

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

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

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

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

+5
09 мая '12 в 10:07
источник

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

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

+4
28 авг. '12 в 4:36
источник

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

+3
04 июл. '12 в 18:46
источник

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

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
23 сент. '14 в 21:55
источник

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

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

+3
02 янв. '14 в 5:10
источник

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

+3
21 янв. '13 в 11:04
источник

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

+3
28 окт. '14 в 8:07
источник

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

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

+1
06 янв. '16 в 12:14
источник

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

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

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

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

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

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

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

0
12 февр. '18 в 12:38
источник

Посмотрите другие вопросы по меткам или Задайте вопрос