В настоящее время наша команда разработчиков настраивает все веб-сайты, на которых они работают, в IIS на своей локальной машине. Мы думаем переключиться на использование встроенного сервера разработки ASP.NET.
Это хорошая идея? Каковы преимущества/недостатки использования ASP.NET dev Server? Есть ли какие-либо ошибки, о которых мы должны знать?
Спасибо.
Примечание: Работа в Win XP/IIS 5/VS2005
Edit:
Не понял, что это называется Cassini.. Больше ответов для Cassini v IIS здесь.
Нет ничего, что ASP.NET Dev WebService не может сделать, что IIS не может (вы можете установить точки останова и т.д., просто присоедините отладчик VS к среде выполнения ASP.NET).
Тем не менее, ASP.NET Dev WebService не представляет собой настоящую производственную среду, и поэтому вы можете быть пойманы gotchas, чего вы не ожидаете при развертывании на производство.
Из-за этого я требую, чтобы вся разработка была выполнена с использованием IIS на локальной машине. Для настройки сайта в IIS не требуется много работы.
Это очень хорошая идея. Вот несколько причин для:
Единственный аргумент, который я знаю, состоит в том, что есть пара очень редких случаев, когда встроенный сервер Cassini точно не имитирует IIS, потому что вы используете нечетные номера портов. Я сомневаюсь, что вы когда-нибудь столкнетесь с ними, а с использованием Cassini в качестве основной среды для разработчиков не препятствует разработчикам также иметь доступ к IIS на машине. На самом деле, моя предпочтительная настройка - это Cassini для большинства небольшая работа, затем разверните ее в локальный IIS для более глубокого тестирования, прежде чем переводить код обратно в общий репозиторий источников.
[изменить]
Забыл о переписывании URL. Для этого вам нужен IIS. Примером ограничения встроенного XP IIS является то, что вы ограничены одним сайтом в XP (может иметь несколько приложений, но это другое).
Мне пришлось переключиться (назад) в IIS для одного проекта, потому что мне нужно было установить несколько виртуальных каталогов, которые невозможно на веб-сервере разработки ASP.NET.
Как я сказал здесь: fooobar.com/questions/107048/... ваши разработчики должны знать, что Cassini работает как локальный пользователь, который обычно является учетной записью администратора для разработчиков. Разработчик сможет получить доступ к любому файлу или ресурсу, который может использовать их учетная запись, что сильно отличается от того, что они будут видеть на сервере IIS 6.
Другое дело, что довольно большой getcha - отладка веб-сервисов намного проще с использованием IIS и vdirs, а не отдельных экземпляров Cassini.
Я использовал оба метода, и я предпочитаю использовать IIS локально и использовать встроенный сервер. По крайней мере, вы более согласуетесь с окончательной настройкой развертывания.
Я знаю, что в какой-то момент у меня возникла проблема с аутентификацией, которая не работает должным образом на Cassini (встроенном сервере разработки)
Кроме того, если вам нужно протестировать такие вещи, как плагины ISAPI (например, репитер), я не уверен, как это делается на Cassini.
Постоянно меняющийся порт также довольно смущает меня. Кроме того, для каждого веб-проекта в вашем решении он запускает еще один экземпляр сервера Casini, каждый из которых занимает от 20 до 50 МБ памяти.
Я использую IIS все время, это довольно легко настроить, и вы, ребята, уже это делаете...
Кроме того, при использовании IIS 5.1 не забудьте получить JetStat IIS Admin, он добавляет функциональность, которая отключена из коробки в IIS 5, например, возможность установки нескольких сайтов.
У меня возникли следующие ограничения с сервером asp.net dev:
не поддерживает виртуальные директории. Если они вам нужны в вашем приложении, IIS, кажется, ваш единственный выбор
Классические страницы asp не запускаются в dev-сервере. Поэтому, если у вас есть смешанное веб-приложение (например, у меня сейчас у моего клиента), IIS представляется решением
Если вам нужен пользовательский интерфейс администратора для настройки параметров, IIS работает лучше
Конечно, IIS требует, чтобы вы были локальным администратором.
Другое замечание, которое я заметил, это то, что Cassini работает как 32-битный процесс, и вы не контролируете его, тогда как вы можете управлять пулом приложений вашего приложения IIS, чтобы запретить 32-битное (если ваш IIS работает на 64 -бит-сервер). Это становится особенно важным, если ваше веб-приложение будет вызывать API в 64-битных процессах, таких как SharePoint Foundation/Server 2010. Когда вы отлаживаете свое веб-приложение с помощью Cassini в качестве сервера отладки, вы получите "Веб-приложение по URL-адресу не быть найденным. Убедитесь, что вы правильно набрали URL-адрес" введите ошибки при создании объектов. Если вы отлаживаете использование IIS с приложением, запущенным в пуле приложений, который работает как 64-разрядный, с идентификатором, который позволяет получить доступ к базе данных sharepoint, вы сможете правильно отлаживать.
В VS12 сервер разработки работает медленно, занимает несколько секунд, чтобы загрузить файл размером 2 килобайта. Это не произошло в vs10. Когда у вас есть куча файлов jquery и css, это настоящая проблема. Также каждая страница запрашивает все файлы css/js. Очень медленное регрессионное тестирование.
Основной проблемой, с которой я столкнулся с сервером dev, является SerializationExceptions с пользовательскими принципалами безопасности, хранящимися в контексте потока. Подробности здесь.