Я знаю, что это не отвечает на ваш вопрос полностью, но я хотел бы поделиться своим опытом.
У меня есть консольное приложение Windows, которое по расписанию вызывает службы WCF, размещенные в IIS. В этой архитектуре IIS фактически совершенно не нужен и является лишь дополнительным компонентом общего решения. Это было действительно включено в решение по маркетинговым причинам, чтобы улучшить продукт, а не по техническим причинам.
Это основные проблемы, с которыми я сталкиваюсь, и почему я бы не стал использовать IIS, если бы мог, по техническим причинам, и это относится к моему опыту. Обратите внимание: я не говорю, что размещение служб WCF в IIS - плохая идея. Я просто высказываю свои мысли о продукте, над которым я сейчас работаю.
- Наличие IIS в цикле означает наличие другой системы в общем решении. Это, в свою очередь, добавляет сложности вашему развертыванию. У некоторых клиентов IIS6, у других - 7. Хотя на первый взгляд эти различия могут показаться небольшими. Не заблуждайтесь, они по-прежнему разные, то есть вы добавляете больше возможностей для различий в среде, если вы развертываете свой продукт для разных клиентов. НЕ недооценивайте эти различия. У меня даже есть клиенты, пытающиеся запустить мои службы WCF в семействе сайтов SharePoint (да!). Дело в том, что гораздо больше, чем вы думаете, может пойти не так.
- IIS также рассматривает AppPool, который может потребоваться настроить в зависимости от сложности вашего продукта. Для этого AppPool требуется идентификация, что еще больше усложнит ваше общее решение.
- У меня были некоторые проблемы, когда однопоточный сервис иногда имел «интересный» - поток прерывания сообщений. Хотя я все еще пытаюсь выяснить точную причину, в глубине души я искренне надеюсь, что это как-то не связано с IIS. Дело в том, что у меня не было бы этого соображения, если бы я исключил IIS из общего решения.
- Я слышал дискуссии о том, что IIS является более надежной средой размещения для служб WCF по сравнению с самостоятельным размещением. Я не совсем уверен, что это имеет какое-то значение. Если вы знаете, что делаете, не должно быть оснований для ненадежности службы, которую вы сами принимаете. Но я полагаю, что для реализации некоторых автоматических функций, которые вы получаете в IIS, требуется больше усилий, например, утилизация WP.
- Я не в целом недоволен IIS в цикле, но мне неприятно, когда я передаю продукт для развертывания, и консультанты без сильной технической подготовки вынуждены настраивать приложение IIS. Обычно что-то может пойти и пойдет не так, и для того, чтобы вмешаться и решить, нужно привлечь кого-то с большим техническим опытом. Если вы используете хостинг самостоятельно, вы можете упростить упаковку приложения для развертывания.
- Извините, что повторяю, но если вы выберете IIS, в вашем решении будет 2 приложения, а не 1, даже если деловая сторона вашей организации будет рассматривать приложение только как одно подразделение, по существу не понимая всей сложности решения, которое вы реализуете. Например: почему у нас есть 2 файла конфигурации? Почему мы должны настроить почту дважды? Почему мы должны развертывать библиотеки DLL в 2 местах. Эти вопросы задают много.
- Наконец, я подумал, что упомяну, если вы работаете удаленно или через VPN для развертывания на клиентах, ситуация становится еще хуже, иногда у консультанта есть доступ к чувствительным областям, которых у вас нет. Как разработчик постарайтесь исключить как можно больше дополнительного багажа из вашего общего решения. Также отметим, что администратор sys может иногда выполнять удобный сброс IIS, если ваше приложение размещается рядом с другими, они сбрасывают ваши службы.
Меньше систем в моем опыте = меньше может пойти не так. Но вам нужно решить, есть ли у вас навыки для реализации надежных услуг самостоятельного размещения. Все это, в свою очередь, напрямую связано со стоимостью разработки, развертывания и обслуживания.