Поделиться через


Развертывание службы WCF, размещенной в IIS

Разработка и развертывание службы Windows Communication Foundation (WCF), размещенной в службы IIS (IIS), состоит из следующих задач:

  • Убедитесь, что службы IIS, ASP.NET, WCF и компонент активации WCF правильно установлены и зарегистрированы.

  • Создайте новое приложение IIS или повторно используйте существующее приложение ASP.NET.

  • Создайте SVC-файл для службы WCF.

  • Развертывание реализации службы в приложение IIS.

  • Настройте службу WCF.

Подробное пошаговое руководство по созданию службы WCF, размещенной в IIS, см. в статье "Практическое руководство. Размещение службы WCF в IIS".

Проверка правильности установки и регистрации IIS, ASP.NET и WCF

ДЛЯ правильной работы служб WCF, IIS и ASP.NET необходимо установить для правильной работы служб WCF, размещенных в IIS. Процедуры установки WCF (в рамках платформа .NET Framework), ASP.NET и IIS зависят от операционной системы. Дополнительные сведения об установке WCF и платформа .NET Framework см. в разделе "Установка платформа .NET Framework для разработчиков". Чтобы установить СЛУЖБЫ IIS в Windows 10, откройте программы и компоненты в панель управления, а затем выберите "Включить или отключить компоненты Windows". В компонентах Windows выберите службы IIS и нажмите кнопку "ОК".

Windows Features with IIS highlighted

Инструкции по установке IIS в других операционных системах см. в статье "Установка IIS в Windows Vista и Windows 7 " и установка IIS 8.5 в Windows Server 2012 R2.

Процесс установки для платформа .NET Framework автоматически регистрирует WCF в IIS, если службы IIS уже присутствуют на компьютере. Если службы IIS установлены после платформа .NET Framework, необходимо зарегистрировать WCF в IIS и ASP.NET. Это можно выполнить указанным ниже способом в зависимости от операционной системы.

Создание нового приложения служб IIS или повторное использование существующего приложения ASP.NET

Службы WCF, размещенные в IIS, должны находиться в приложении IIS. Вы можете создать новое приложение IIS для размещения служб WCF исключительно. Кроме того, можно развернуть службу WCF в существующем приложении, которое уже размещает содержимое ASP.NET 2.0 (например, страницы .aspx и веб-службы ASP.NET [ASMX]). Дополнительные сведения об этих параметрах см. в разделах "Размещение WCF параллельно с ASP.NET" и "Размещение служб WCF в режиме совместимости ASP.NET" в службах WCF и ASP.NET.

Обратите внимание, что службы IIS 6.0 и более поздние версии периодически перезапускали изолированное объектно-ориентированное приложение программирования. Значение по умолчанию — 1740 минут. Максимальное поддерживаемое значение - 71582 минуты. Этот перезапуск можно отключить. Дополнительные сведения об этом свойстве см. в параметре PeriodicRestartTime.

Создание SVC-файла для службы WCF

Службы WCF, размещенные в СЛУЖБАх IIS, представляются в виде специальных файлов содержимого (SVC-файлов) в приложении IIS. Эта модель подобна модели, согласно которой страницы ASMX представляются внутри приложения IIS в виде ASMX-файлов. SVC-файл содержит директиву обработки WCF (@ServiceHost), которая позволяет инфраструктуре размещения WCF активировать размещенные службы в ответ на входящие сообщения. В приведенном ниже операторе показан наиболее распространенный синтаксис SVC-файла.

<% @ServiceHost Service="MyNamespace.MyServiceImplementationTypeName" %>

Он состоит из директивы @ServiceHost и одного атрибута Service. Значение атрибута Service - имя типа среды CLR реализации службы. Использование этой директивы по существу эквивалентно созданию основного приложения службы с помощью следующего кода.

new ServiceHost( typeof( MyNamespace.MyServiceImplementationTypeName ) );

Можно также создать дополнительную конфигурацию размещения, например список базовых адресов службы. Кроме того, можно применить пользовательскую фабрику ServiceHostFactory , чтобы расширить директиву для использования с пользовательскими решениями по размещению. Приложения IIS, на которых размещаются службы WCF, не несут ответственности за управление созданием и временем существования ServiceHost экземпляров. Управляемая инфраструктура размещения WCF создает необходимый ServiceHost экземпляр динамически при получении первого запроса для SVC-файла. Этот экземпляр не освобождается, пока он не будет явно закрыт кодом или не перезапустится приложение.

Дополнительные сведения о синтаксисе файлов SVC см. в @ServiceHost.

Развертывание реализации службы в приложение IIS

Службы WCF, размещенные в IIS, используют ту же динамическую модель компиляции, что и ASP.NET 2.0. Как и в случае с ASP.NET, можно развернуть код реализации для служб WCF, размещенных в IIS, несколькими способами в различных расположениях, как показано ниже.

  • В виде предкомпилированного DLL-файла, расположенного в глобальном кэше сборок или в каталоге \bin приложения. Предкомпилированные двоичные файлы не обновляются, пока не будет развернута новая версия библиотеки классов.

  • Как некомпилированные исходные файлы, расположенные в каталоге \App_Code приложения. Исходные файлы, расположенные в этом каталоге, запрашиваются динамически при обработке первого запроса приложения. Любые изменения в файлах в каталоге \App_Code приводят к перезапуску и повторной компиляции всего приложения при получении следующего запроса.

  • Как некомпилируемый код помещается непосредственно в SVC-файл. Код реализации также можно найти в встроенном файле SVC службы после директивы @ServiceHost. Любые изменения во встроенном коде приводят к перезапуску и повторной компиляции приложения при получении следующего запроса.

Дополнительные сведения о модели компиляции ASP.NET 2.0 см. в ASP.NET обзоре компиляции.

Настройка службы WCF

Службы WCF, размещенные в IIS, хранят конфигурацию в файле конфигурации приложений Web.config. Службы, размещенные в IIS, используют те же элементы конфигурации и синтаксис, что и службы WCF, размещенные за пределами IIS. Однако для среды размещения IIS присущи следующие ограничения.

  • Базовые адреса размещенных в IIS служб.

  • Приложения, размещающие службы WCF за пределами IIS, могут управлять базовым адресом служб, которые они размещают, передав набор URI ServiceHost базовых адресов конструктору или предоставляя <элемент узла> в конфигурации службы. Службы, размещенные в IIS, не могут управлять своими базовыми адресами; базовым адресом службы, размещенной в IIS, является адрес ее SVC-файла.

Адреса конечных точек для служб, размещенных в IIS

Будучи размещенными в IIS, адреса конечных точек всегда считаются относительными для адреса SVC-файла, представляющего службу. Например, если базовый адрес службы WCF имеет http://localhost/Application1/MyService.svc следующую конфигурацию конечной точки:

<endpoint address="anotherEndpoint" />

Это обеспечивает конечную точку, которую можно получить по адресу http://localhost/Application1/MyService.svc/anotherEndpoint.

Аналогичным образом, элемент конфигурации конечной точки, использующий пустую строку в качестве относительного адреса, предоставляет доступную конечную точку, http://localhost/Application1/MyService.svcкоторая является базовым адресом.

<endpoint address="" />

Для конечных точек служб, размещенных в IIS, следует всегда использовать относительные адреса. Предоставление полного адреса конечной точки (например, ) может привести к ошибкам в развертывании службы, http://localhost/MyService.svcесли адрес конечной точки не указывает на приложение IIS, в котором размещена служба, предоставляющая конечную точку. Использование относительных адресов конечных точек для размещенных служб позволяет избежать таких потенциальных конфликтов.

Доступные типы транспорта

Службы WCF, размещенные в IIS 5.1 и IIS 6.0, ограничены использованием связи на основе HTTP. В этих платформах IIS настройка размещенной службы на использование привязки, отличной от HTTP, приводит к ошибке во время активации службы. Для IIS 7.0 поддерживаемые транспорты включают HTTP, Net.TCP, Net.Pipe, Net.MSMQ и msmq.formatname для обратной совместимости с существующими приложениями MSMQ.

Безопасность транспорта HTTP

Службы WCF, размещенные в IIS, могут использовать безопасность транспорта HTTP (например, схемы проверки подлинности HTTPS и HTTP, такие как базовая, дайджест и встроенная проверка подлинности Windows), если виртуальный каталог IIS, содержащий службу, поддерживает эти параметры. Параметры безопасности транспорта HTTP в привязке размещенной конечной точки должны соответствовать параметрам безопасности транспорта в виртуальном каталоге IIS, который содержит эту привязку.

Например, конечная точка WCF, настроенная для использования проверки подлинности дайджеста HTTP, должна находиться в виртуальном каталоге IIS, который также настроен для разрешения проверки подлинности дайджеста HTTP. Несовпаденные сочетания параметров IIS и параметров конечной точки WCF приводят к ошибке во время активации службы.

См. также