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

Ответ 1

вам лучше прочитать следующее: http://msdn.microsoft.com/en-us/library/aa730880(VS.80).aspx по-моему, это зависит от того, что вы разрабатываете.

Ответ 2

Обе функции и работают аналогично, но по-прежнему отличаются следующими способами:

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

• Мы не можем включать страницы С# и VB в одно веб-приложение.
• Мы можем настроить зависимости между несколькими проектами.
• Невозможно редактировать отдельные файлы после развертывания без повторной компиляции.
• Правильный выбор для корпоративных сред, в которых несколько разработчиков работают для создания, тестирования и развертывания.

Веб-сайт:

• Можно смешивать страницы VB и С# на одном веб-сайте.
• Невозможно установить зависимости.
• Редактировать отдельные файлы после развертывания.
• Правильный выбор, когда один разработчик будет отвечать за создание и управление всем сайтом.

Ответ 3

Проекты веб-приложений более похожи на традиционный проект VS, который имеет файл проекта, скомпилирован за один шаг и т.д.

Проекты веб-сайтов более похожи на классические ASP или PHP-сайты. Файл проекта отсутствует (ссылки хранятся в файле решения), а страницы перекомпилируются динамически на сервере. Хорошая вещь с веб-сайтами заключается в том, что вы можете просто ftp на сервере и изменить файл в текстовом редакторе. Вам не нужно VS. Некоторые могут ненавидеть это, однако.

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

Ответ 4

Если вы используете Team Foundation Server для управления версиями, вам, вероятно, придется использовать проект веб-приложений, так как вам нужен файл .csproj.

У Джеффа Этвуда есть более подробная информация: Проекты веб-сайтов и проекты веб-приложений

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

Ответ 5

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

Ответ 6

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

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

Ответ 7

В Visual Studio 2015 я несколько предпочитаю проекты веб-сайтов над проектами веб-приложений. Я все еще использую визуальную студию, потому что вы получаете Nuget Packaging, вы можете устанавливать пакеты nuget для обоих типов проектов.

Однако в проекте WebSite нет файла проекта, вы просто добавляете папку в свое решение.

Однако у вас все еще есть код, но я предпочитаю его размещать в отдельном проекте.

В проектах WebApp у вас есть свои активы, Css, Views (бритва, aspx и т.д.), контроллеры/коды и т.д. и все это в одном проекте, и оно просто сливается. Я предпочитаю работать с веб-сайтами в две половинки. Передний конец (css, js, images, "html/cshtml/aspx/ashx/.master/etc" ) и задний конец (весь код).

Итак, я создаю проект веб-сайта и библиотеку классов, чтобы сопровождать его (в визуальной студии вы можете добавить ссылки на проект веб-сайта). Я добавляю свою библиотеку классов как зависимость, и весь код находится в библиотеке классов. У вас все еще может быть global.asax, вам просто нужно сказать, что код находится в другой dll (а не той, которую компилирует сайт). MVC, вы просто указываете пространства имен, такие как normal (dll - это ссылка, поэтому существуют пространства имен). И в WebForms вам просто нужно помнить, чтобы указать имя сборки с вашими типами ссылок, в которых находится код.

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

И сторона PLUS - это то, что веб-сайт - это просто папка (без файла проекта), она может быть легко открыта в Visual Studio Code, а другие популярные текстовые редакторы упрощают работу дизайнеров css/js/изображения и т.д. (которые не входят в проект кода). Сохраняя дизайнеров слоев, дизайнер видит только то, что им нужно видеть.

Теперь структура мудрая. Я сохраняю свой локальный код на моей машине в хранилище subversion, используя Tortoise SVN и Visual SVN (магазин java/.net). Чтобы проверить локально, я устанавливаю IIS, и я устанавливаю проект веб-сайта в IIS локально, как и на серверах dev/prod.

Затем я устанавливаю MSDeploy на dev/prod-серверы, и я использую функцию веб-приложения Publish через MSDeploy в visual studio, и я использую преобразования web.config. Поэтому у меня есть преобразования web.config для dev и prod, а основной web.config без преобразований - для локального тестирования (поэтому он работает для всех разработчиков в проекте).

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

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

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