Каковы (не) преимущества использования Cassini вместо IIS?
Я обнаружил, что в некоторых случаях я могу редактировать исходный код во время отладки, есть ли другие преимущества использования встроенного веб-сервера Visual Studio вместо виртуального каталога в IIS?
Я использую Windows XP в своей среде разработки и локальный экземпляр IIS 5. Я работаю над несколькими проектами, поэтому я использую несколько виртуальных каталогов для управления всеми различными сайтами.
Есть ли недостатки?
28 ответов
Встроенный веб-сервер для Visual Studio называется Cassini, и вот некоторые из его ограничений...
- Он может размещать только одно приложение ASP.NET на порт.
- Он не поддерживает HTTPS.
- Он не поддерживает аутентификацию.
- Он отвечает только на запросы localhost.
- Медленный запуск по сравнению с IIS
Все предыдущие ответы - отличные ответы - вот одна ошибка с Кассини, которая может потребовать IIS на Destkop.
Cassini работает в контексте разработчика, а не как пользователь IIS (IUSR_, IWAM или WinXP x64, процесс w3wp). Это может быть немного болезненно, если у вас есть веб-сайт, который обращается к внешним файлам или создает временные файлы. Это наиболее очевидно, когда ваш разработчик работает как администратор своего рабочего стола.
Когда вы переходите на сервер IIS, то, к чему у вас был бы доступ в Cassini, не работает так же. CACLing с IIS_WPG обычно это все, что нужно для исправления, но если ваш разработчик не задумывается об этом, они быстро разочаруются в своем развертывании.
Веб-сервер Visual Studio менее прощающий // в пути.
Он откажется обслуживать ссылку как:http://localhost:52632/main//images/logo.jpg где IIS будет делать.
Это довольно непонятно, но означает, что нам нужно многое исправить, чтобы избавиться от всех // вхождения.
Встроенный сервер хорошо работает для крупных корпораций, которые не хотят предоставлять разработчикам доступ администратора на своих компьютерах для настройки IIS.
Еще один недостаток, с которым я столкнулся - это сайт, прошедший проверку подлинности с помощью форм IPrincipal/IIdentity, Кассини переключит AppDomains без предупреждения (или уведомления).
Проверьте этот блог для получения дополнительной информации. Головная боль от этого заставила меня бросить Кассини и придерживаться IIS.
Есть ошибка в том, как встроенный сервер обрабатывает HTTPModules - есть обходной путь, но я ненавижу вставлять код, который никогда не понадобится в производстве.
Вам необходимо запустить Visual Studio, чтобы использовать его (при нормальных обстоятельствах)
Он отвечает только на localhost, поэтому вы не можете дать ссылку
http://simon-laptop:37473/app1другу для просмотра вашего сайта по сетиБольшое разочарование: заставить фиддлер работать сложнее, потому что трафик localhost не передается через прокси.
Редактировать: используя http://ipv4.fiddler:37473 это лучший способ заставить Fiddler работать с ним.
Если вы "веб-ссылка" URL для веб-служб, которые находятся на встроенном веб-сервере, порт может измениться. Если вы не установили "Определенный порт", упомянутый на странице параметров проекта-> Свойства.
Это то, к чему я привык. Я всегда устанавливаю определенный порт. Теперь, когда иногда происходит сбой веб-сервера (у меня такое было), я просто меняю номер порта, и все хорошо. Я думаю, что перезапуск также исправит это.
Встроенный сервер означает, что разработчику не нужно знать, как настроить IIS для тестирования своего сайта.
Вы можете утверждать, что это недостаток, и что разработчик Windows должен знать, по крайней мере, столько IIS. Или вы можете утверждать, что разработчик, который не является системным администратором, вообще не должен возиться с веб-сервером.
Cassini также не поддерживает классические страницы ASP. Это проблема только для устаревших проектов, где старые страницы ASP все еще существуют (например, наше веб-приложение в работе).
Встроенный сервер не так настраиваем, и он работает на нечетном порту, поэтому, если вы рассчитываете на конкретное поведение, это может быть проблематично.
Кассини - легкий веб-сервер для тестирования. Идея состоит в том, что разработчику не нужно устанавливать и настраивать IIS для тестирования своего приложения. Используйте IIS, если вы знакомы с ним, и у вас есть его настройки, и ваш ящик может обработать его. Кассини не является заменой.
Вот причина для третьего пути: хотя UWS Pro, вероятно, ближе к IIS, чем Cassini (хотя он вдохновлен Cassini и принадлежит поставщику форка UltiDev Cassini), его основная цель - распространять его вместе с приложениями ASP.NET.
Когда вы используете IIS в Vista или Windows 7 с включенным UAC, вы должны запустить Visual Studio с правами администратора. Если вы сделаете это, вы не сможете перетащить каплю из своей оболочки в Visual Studio (даже если вы запускаете экземпляр explorer.exe от имени администратора).
По этой причине я использую Cassini для большинства проектов.
Это старая тема, начатая 2 года назад. Я просто наткнулся на UtilDev Cassini, пока гуглил. Выглядит многообещающе для меня. По крайней мере, у него есть возможность запускать несколько сайтов одновременно. Эта функция очень полезна для меня, потому что я работаю на 2 разных сайтах и вынужден постоянно переключаться между ними с помощью IIS.
К сведению, 64-разрядная версия Windows XP поставляется с IIS 6.
Если вы работаете дома с помощью XP Home, вы не можете установить IIS локально.
Я часто беру лучшее из обоих миров и создаю приложение в IIS, а также использую встроенный веб-сервер для более эффективной отладки.
Установите IISAdmin, и вы сможете настроить отдельные сайты в IIS 5 вместо использования виртуальных каталогов.
Также через IIS вам не нужно беспокоиться об автоматическом запоминании и установке глупого номера порта в вашем локальном URL-адресе. Это что-то напуганное с Кассини... большая боль в заднице. Кто хочет запомнить какой-то номер порта. Просто запустите этот проклятый сайт в IIS..plain и просто.
Мы также видели некоторые проблемы со встроенным сервером VS в отношении некоторых сторонних элементов управления, которые помещают свои скрипты в папку \ aspnet_client. Поскольку папка отсутствует, когда вы не работаете под IIS, элементы управления не работают. Кажется, намного проще всегда работать с IIS и избегать странных проблем.
Встроенный веб-сервер немного менее надежен, чем IIS, но не требует настройки, поэтому это просто компромисс.
Возможно, вы не всегда хотите, чтобы ваши проекты разработки были представлены на вашем сервере IIS (даже на вашем локальном сервере IIS), поэтому встроенный сервер подходит для этого.
Однако, если ваше приложение будет обращаться к ресурсам за пределами нормы для веб-приложения, вам может потребоваться частая отладка в IIS, так что ваше приложение будет работать с ограниченными разрешениями, и вы сможете увидеть, где будут находиться болевые точки.
Я обнаружил одно отличие: сервер разработки обрабатывает загрузку файлов иначе, чем IIS. Вы не можете перехватить ошибку, если загружаемый файл больше, чем ваш параметр Max_File_Size. Страница просто умирает и возвращает 500.
Еще одним недостатком является то, что он отправляет каждый запрос через глобальный asax-файл, который включает в себя все запросы на изображения и таблицы стилей. Это означает, что если у вас есть код, который работает с именами файлов, например поиск, то вспомогательные файлы также будут обрабатываться.
Если ваш проект находится в каталоге IIS, вы все равно можете редактировать код, зависит только от того, опубликован он или нет. Вы столкнетесь с такими проблемами на Cassini vs IIS, когда будете отлаживать определенные сценарии, основанные на разрешениях, такие как аутентификация kerberos и ntlm, а также такие проблемы, как сжатие сервера и т. Д. В целом, Cassini все еще в порядке для разработки, но убедитесь, что вы делаете обширное тестирование при публикации в IIS.