Различие между 'веб-сайтом' и 'проектом' в Visual Studio [дубликат]

У них есть различные цели.

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

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

Я не копирую определение этих 2, так как тот просто был отвечен.

Итак, почему использование один по другому?

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

Профессионалы

• можно сделать тонкие настройки на сайт прямо на веб-сервере
• , Развертывание так же просто как копирование папки

Недостатки

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

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

Профессионалы

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

• , поскольку Вы компилируете его на своей машине, все проверило синтаксис в той точке*

Недостатки

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

• Любые изменения должны быть сделаны на Вашей машине, скомпилированной, и совершенно новая версия, отправленная в веб-сервер*

, *The aspx/html файлы являются только синтаксисом, проверенным при включении этого в опциях сборки все же. Также возможно отредактировать эти файлы на сервере, если они не компилируются в Ваш проект.

3) проекты WebApplication buildable MSBuild. WebSites не (без большой тонкой настройки). При использовании TeamSystem с автоматизированными сборками тогда, это - способ пойти.

Сайты являются исходной.NET 2003 года способ сделать сеть dev. По моему опыту, они чрезвычайно проблематичны начиная с недостатка в определении проекта, они не могут быть снова использованы и иметь проблемы с модульным кодированием, иметь проблемы с интеграцией TeamSystem и пространством имен. Непосредственные связывают с доменом, и отсутствие реальной абстракции публикации создает проблемы обслуживания по линии.

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

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

1. Сначала был проект веб-приложения (он вел себя так же к текущему проекту веб-сайта). Они изменили его для отражения то, что запросили некоторые пользователи. Однако люди хотели старую функциональность назад, таким образом, они повторно ввели проект веб-сайта, который ведет себя как исходный проект веб-приложения.

2. я - и мое рабочее место - предпочитаем проект

3. веб-сайта, Нам нравится этот, файлы веб-сайта являются файлами в файловой системе (никакая потребность добавить их вручную)

4. , Никакая идея

Вот не является двумя статьями, которые я нашел об обоих:

http://damieng.com/blog/2008/02/07/web-site-vs-web-application

http://www.dotnetspider.com/resources/1520-Difference-between-web-site-web-application.aspx

Примечание: Много вопросов с веб-сайтами было решено с веб-проектом

развертывания Обновление: Зафиксированный точка 1, веб-приложение было там первое

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

основное различие для веб-сайта, некоторые файлы должны быть помещены в определенные каталоги (файлы кода должны быть помещены в каталог 'App_Code'), помимо которого, это является довольно прямым.

При наличии скомпилированного кода для развертывания важно для Вас, и Вы хотите единственный DLL (настроенный против нескольких, которые создаются, когда Вы делаете нормальное публикует для веб-сайта), тогда Вы захотите получить это дополнение: http://msdn.microsoft.com/en-us/asp.net/aa336619.aspx

Самая большая разница, о которой никто не упомянул (кроме упомянутой Аннакатой), заключается в том, что с моделью, где все скомпилировано в одну DLL, вы полностью контролируете классы, которые ваше приложение генерирует. Вы знаете, где они находятся, и всегда можете ссылаться на них из любого другого места в приложении.

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

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

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

Проект веб-сайта (ключ к разгадке в названии) действительно хорош только для несложных «брошюр» сайтов (где страницы состоят из статического содержания) в отличие от веб-приложений .