Когда я запускаю новый проект ASP.NET в Visual Studio, я могу создать веб-приложение ASP.NET или создать веб-сайт ASP.NET.
В чем разница между веб-сайтом ASP.NET и веб-сайтом ASP.NET? Почему я должен выбирать один над другим?
Является ли ответ разным в зависимости от того, какую версию Visual Studio я использую?
Веб-сайт:
Проект веб-сайта компилируется на лету. В итоге вы получите гораздо больше 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.
Веб-сайт - это то, что вы развертываете на веб-сервере ASP.NET, таком как IIS. Просто куча файлов и папок. Нет ничего на веб-сайте, который связывает вас с Visual Studio (нет файла проекта). Генерация кода и компиляция веб-страниц (например,.aspx,.ascx,.master) выполняются динамически во время выполнения и изменения этих файлов обнаруживаются каркасом и автоматически перекомпилируются. Вы можете поместить код, который вы хотите делиться между страницами в специальной папке App_Code, или вы можете предварительно скомпилировать его и поместить сборку в корзину папку.
Веб-приложение - это специальный проект Visual Studio. Основное отличие веб-сайтов заключается в том, что при создании проекта все файлы кода скомпилированы в одну сборку, которая помещается в каталог bin. Вы не разворачиваете файлы кода на веб-сервер. Вместо того, чтобы иметь специальную папку для файлов общего кода, вы можете поместить их в любом месте, как и в библиотеке классов. Поскольку веб-приложения содержат файлы, которые не предназначены для развертывания, такие как файлы проекта и кода, theres Опубликовать команду в Visual Studio для вывода Web Сайт в указанное место.
Развертывание файлов общего кода, как правило, является плохой идеей, но это не значит, что вам нужно выбрать веб-приложение. У вас может быть веб-сайт, который ссылается на проект библиотеки классов, который содержит весь код для веб-сайта. Веб-приложения - это просто удобный способ сделать это.
Этот раздел посвящен файлам .aspx и .ascx. Этот раздел становится все более актуальным в новых инфраструктурах приложений, таких как ASP.NET MVC и веб-страницы ASP.NET, которые не используют файлы codebehind.
Имея все файлы кода, скомпилированные в одну сборку, включая codebehind файлы .aspx-страниц и .ascx-элементов управления, в веб-приложениях, которые у вас есть перестроить для каждого небольшого изменения, и вы не можете вносить изменения в жизнь. Это может быть настоящей болью во время разработки, поскольку вы должны продолжать перестраивать, чтобы видеть изменения, в то время как изменения веб-сайтов обнаруживаются средой выполнения, а страницы/элементы управления автоматически перекомпилируются.
Наличие времени выполнения управления сборками codebehind для вас меньше, так как вам не нужно беспокоиться о том, чтобы предоставить страницы/управлять уникальными именами или организовать их в разных пространствах имен.
Я не говорю, что развертывание файлов кода всегда является хорошей идеей (особенно не для файлов с общим кодом), но файлы codebehind должны содержать только код, который выполняет специфические задачи пользовательского интерфейса, обработчики событий проводки и т.д. Ваше приложение должно быть слоистым, чтобы важный код всегда попадал в папку Bin. Если это так, то развертывание файлов codebehind не должно считаться вредным.
Другим ограничением веб-приложений является то, что вы можете использовать только язык проекта. На веб-сайтах вы можете иметь некоторые страницы на С#, некоторые в VB и т.д. Нет необходимости в специальной поддержке Visual Studio. Это красота расширяемости поставщика сборки.
Кроме того, в веб-приложениях вы не обнаружите обнаружение ошибок в страницах/элемента управления, поскольку компилятор компилирует только классы кода, а не код разметки (в MVC вы можете исправить это с помощью опции MvcBuildViews), которая компилируется во время выполнения.
Поскольку веб-приложения представляют собой проекты 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
Веб-сайт= использовать, когда веб-сайт создан графическими дизайнерами, а программисты редактируют только одну или две страницы
Веб-приложение= использовать, когда приложение создано программистами, и графические дизайнеры редактируют только один или два выгруженных/изображения.
Веб-сайты могут быть обработаны с использованием любых инструментов HTML без необходимости иметь студию разработчиков, поскольку файлы проектов не нуждаются в обновлении и т.д. Веб-приложения лучше всего, когда команда в основном использует студию разработчиков и имеет высокое содержание кода.
(Некоторые ошибки кодирования находятся в веб-приложениях во время компиляции, которые не встречаются на веб-сайтах до времени выполнения.)
Предупреждение: Я написал этот ответ много лет назад и не использовал Asp.net с тех пор. Я ожидаю, что теперь все изменится.
Если у вас нет конкретной потребности в динамически скомпилированном проекте, не используйте проект веб-сайта.
Почему? Поскольку проект веб-сайта приведет вас к стене, когда вы пытаетесь изменить или понять свой проект. Статические функции поиска текста (например, поиск, рефакторинг) в Visual Studio будут выполняться навсегда в любом проекте с разумным размером. Для получения дополнительной информации см. Вопрос "Переполнение стека" Медленно "Найти все ссылки" в Visual Studio.
Я действительно не понимаю, почему они бросили веб-приложения в Visual Studio 2005 для создающего боль, безумного дренажа, производительности проекта веб-сайта carbuncle.
В MSDN есть статья, которая описывает различия:
Сравнение проектов веб-сайтов и проектов веб-приложений
Кстати: есть несколько похожих вопросов по этой теме, например:
Это может показаться немного очевидным, но я думаю, что это неправильно понято, потому что Visual Studio 2005 только первоначально отправляется на веб-сайт. Если ваш проект имеет дело с сайтом, который является довольно ограниченным и не имеет большого логического или физического разделения, веб-сайт в порядке. Однако, если это действительно веб-приложение с различными модулями, где многие пользователи добавляют и обновляют данные, вам лучше работать с веб-приложением.
Самый большой профи модели веб-сайта заключается в том, что все в разделе app_code динамически компилируется. Вы можете делать обновления файлов С# без полного перераспределения. Однако это приносит огромную жертву. Много вещей происходит под крышками, которые трудно контролировать. Пространства имен трудно контролировать, а использование определенных DLL файлов по умолчанию выходит за окно под app_code, поскольку все динамически компилируется.
Модель веб-приложения не имеет динамической компиляции, но вы получаете контроль над вещами, о которых я упоминал.
Если вы занимаетесь разработкой n-уровневого уровня, я настоятельно рекомендую модель веб-приложения. Если вы делаете ограниченный веб-сайт или быстро и грязно, модель веб-сайта может иметь преимущества.
Более подробный анализ можно найти в:
Из экзамена 70-515 экзаменационного экзамена MCTS для самостоятельного курса:
С веб-приложением (проектом),
- Вы можете создать приложение MVC.
- Visual Studio хранит список файлов в файле проекта (.csproj или .vbproj), а не полагается на структуру папок.
- Вы не можете смешивать Visual Basic и С#.
- Вы не можете редактировать код, не останавливая сеанс отладки.
- Вы можете установить зависимости между несколькими веб-проектами.
- Вы должны скомпилировать приложение перед развертыванием, что не позволяет вам тестировать страницу, если другая страница не будет компилироваться.
- Вам не нужно хранить исходный код на сервере.
- Вы можете управлять именем и версией сборки.
- Вы не можете редактировать отдельные файлы после развертывания без повторной компиляции.
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 и веб-сайтом является компиляция. Поэтому, если вы работаете над большим проектом, где несколько человек могут изменить его, лучше использовать веб-сайт. Но если вы делаете небольшой проект, вы также можете использовать веб-приложение.
Это зависит от того, что вы разрабатываете.
Веб-сайт, ориентированный на контент, будет часто меняться, и сайт лучше для этого.
Приложение имеет тенденцию хранить свои данные в базе данных, а его страницы и код редко меняются. В этом случае лучше иметь веб-приложение, где развертывание сборок намного более контролируется и имеет лучшую поддержку для модульного тестирования.
Одним из ключевых отличий является то, что веб-сайты компилируются динамически и создают "на лету" сборки. Веб-приложения компилируются в одну большую сборку.
Различие между ними было устранено в Visual Studio 2008.
Да, веб-приложение намного лучше, чем веб-сайты, потому что веб-приложения дают нам свободу:
Чтобы иметь несколько проектов под одним зонтиком и создать проект зависимости между ними. Например. для PCS мы можем иметь в сети приложение -
Для запуска модульных тестов кода, который находится в файлах классов, которые связанные с страницами ASP.NET
Приложения обычно скомпилируются перед развертыванием, когда сайт использует каталог app_code. Когда что-либо изменяется в папке с кодом приложения, сервер будет перекомпилировать код. Это означает, что вы можете добавлять/изменять код с веб-сайта на лету.
Преимущество приложения заключается в том, что повторная компиляция не производится, поэтому начальное время запуска будет быстрее.
Я рекомендую вам посмотреть видео Проекты веб-приложений и проекты веб-развертывания на веб-сайте ASP.NET, в котором объясняется различие в деталях, это был мне очень полезен.
Кстати, не путайте название, большая часть видео объясняет разницу между проектами веб-сайтов и проектами веб-приложений и почему Microsoft повторно представила проекты веб-приложений в Visual Studio 2005 (как вы, вероятно, уже знаете, он первоначально был отправлен только с веб-проектами, тогда в SP1 были добавлены проекты веб-приложений). Отличное видео, которое я рекомендую всем, кто хочет узнать разницу.
"Веб-сайт" имеет свой код в специальном каталоге App_Code и скомпилирован в несколько DLL (сборок) во время выполнения. "Веб-приложение" предварительно скомпилировано в одну DLL.
Веб-сайт и проект → веб-сайт - это два разных метода создания приложения ASP.NET с использованием visual studio. Один из них безпроектирован, а другой - это среда проекта. Различия:
нет принципиальной разницы в использовании любого подхода. Но если вы создаете веб-сайт, который займет больше времени, выберите среду проекта.
Это всегда зависит от требований вашего клиента. ASP.NET включает в себя гибкие функции, необходимые пользователю для обеспечения безопасности и простого обслуживания вашего приложения.
Вы можете думать о веб-приложении как двоичном файле, который выполняется внутри рамки ASP.NET. И Веб-сайты в качестве статической веб-страницы, которую вы можете просмотреть и легко развернуть исходный код.
Но преимущество и недостатки этих двух технологий ASP.NET - это то, что хорошо.
Модель проекта веб-приложения
Модель проекта веб-сайта
Веб-сайты. Файл решения не будет создан. Если мы хотим создавать веб-сайты, вам не нужна визуальная студия.
Веб-приложение. Будет создан файл решения. Если мы хотим создать веб-приложение, вам нужна визуальная студия. Он создаст единственный файл .dll в папке bin.
В проектах веб-приложений Visual Studio нуждается в дополнительных файлах .designer для страниц и пользовательских элементов управления. Проекты веб-сайта не требуют этих накладных расходов. Сама разметка интерпретируется как дизайн.
Определенно веб-приложение, один DLL файл и прост в обслуживании. Но сайт более гибкий; вы можете редактировать файл aspx на ходу.
WebSite: Он автоматически создает папку app_code и публикует его на сервере, а после этого, если вы делаете некоторые изменения в любом конкретном файле или странице, вам не нужно компилировать все файлы.
Веб-приложение Он автоматически генерирует файл решений, который не создается на веб-сайте, и если вы меняете в одном файле, вы должны скомпилировать полный проект, чтобы отобразить его изменения.
Веб-приложения требуют больше памяти, вероятно, потому что у вас нет выбора, кроме как собрать в одну сборку. Я только что преобразовал большой устаревший сайт в веб-приложение, и у меня возникли проблемы с нехваткой памяти, как во время компиляции, так и с сообщением об ошибке, как показано ниже:
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()
Моя рекомендация по преобразованию более крупных сайтов на устаревшем оборудовании с ограниченным объемом памяти - выбрать вариант возврата к модели веб-сайта. Даже после первоначального успеха проблема может подкрасться позже.
В веб-приложении вы можете создавать слои своей функциональности проекта и создавать между ними взаимозависимости, деля его на многие проекты, но вы никогда не сможете сделать это на веб-сайте.
Здесь Web Supportive Application - пример веб-сайта. Веб-сайт и веб-приложение могут быть динамическими/статичными, что зависит от требований, вот пример, чтобы понять работу веб-сайта и веб-приложения.
Чтобы обобщить некоторые из приведенных выше ответов:
Гибкость. Можете ли вы сделать живые изменения на веб-странице?
Веб-сайт: возможно. Pro: краткосрочные выгоды. Con: долгосрочный риск проектного хаоса.
Веб-приложение: Con: невозможно. Отредактируйте страницу, запишите изменения в исходный элемент управления, затем создайте и разверните весь сайт. Pro: поддерживать качественный проект.
Проблемы развития
Веб-сайт: простая структура проекта без файла .csproj. Две страницы .aspx могут иметь одно и то же имя класса без конфликтов. Случайное имя каталога проекта, которое приводит к ошибкам сборки, например почему .net-инфраструктура конфликтует с собственным созданным файлом и почему .net framework конфликтует с собственный файл. Pro: Простой (упрощенный). Con: неустойчивый.
Веб-приложение: структура проекта похожа на проект WebForms с файлом .csproj. Названия классов asp-страниц должны быть уникальными. Pro: Простой (умный). Con: none, потому что веб-приложение все еще просто.