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

Сценарий Windows PowerShell для определения расположения конфигурации реакции службы на событие

  • Статья

В WCF 4.0 добавлена возможность объединять реакции на события из разных файлов конфигурации в иерархии конфигурации. Это позволяет определить общие реакции на события в высокоуровневых файлах конфигурации (например, в файле web.config уровня сайта), задавая дополнительные реакции в файлах конфигурации более низких уровней. В следующем примере показано, как это работает:

Файл web.config уровня сайта

  <configuration>
    <system.serviceModel>
      <behaviors>
        <serviceBehaviors>
          <behavior name="MyBehavior">
            <serviceDebug includeExceptionDetailInFaults="True" />
            <serviceMetadata httpGetEnabled="True" />
          </behavior>
        </serviceBehaviors>
      </behaviors>
    </system.serviceModel>
  </configuration>

Файл web.config уровня приложения

  <configuration>
    <system.serviceModel>
      <behaviors>
        <serviceBehaviors>
          <behavior name="MyBehavior">
            <etwTracking profileName="Troubleshooting Tracking Profile" />
          </behavior>
        </serviceBehaviors>
      </behaviors>
    </system.serviceModel>
  </configuration>

Служба WCF, расположенная внутри приложения и использующая «MyBehavior», фактически наследует конфигурации serviceDebug/serviceMetadata и etwTracking. Дополнительные сведения об объединении конфигураций реакций на события см. в статьях Объединение реакций на события в конфигурации WCF 4.0 (https://go.microsoft.com/fwlink/?LinkId=194422) и Поведение объединения конфигураций .NET по умолчанию (https://go.microsoft.com/fwlink/?LinkId=194423).

Несмотря на гибкость конфигурации с объединением реакций на события иногда могут возникать проблемы, поскольку фактическая конфигурация реакций службы на события может отличаться от того, что указано в локальном файле web.config. В этом примере показано, как создать сценарий PowerShell в виде командлета, анализирующий конфигурацию реакций службы на события и сообщающий о том, в каких файлах конфигурации можно найти действующие параметры.

Примечание

Примеры предназначены только для образовательных целей. Они не предназначены для использования в рабочей среде и не тестировались в ней. Корпорация Майкрософт не предоставляет техническую поддержку для этих примеров.

Предварительные условия

Пользователи должны уметь работать со сценариями Windows PowerShell и командлетами AppFabric.

В примере предполагается следующее:

  • Установлена среда PowerShell v2.

  • Была выполнена установка AppFabric по умолчанию.

Расположение примера и файлов

В пакет файлов примера входят следующие файлы:

  • Readme.mhtml

  • Code\detectServiceBehaviorConfigLocation.ps1

Установка и запуск этого примера

  1. В следующем примере показано, как запустить командлет-сценарий в консоли PowerShell:

    PS> cd <samples>\Samples\Management\DetectServiceBehaviorConfigLocation\Code

PS> . .\detectServiceBehaviorConfigLocation.ps1 #the first dot is for loading the ps1 as a function library

PS> Get-ServiceBehaviorConfigLocation -SiteName "Default Web Site" -VirtualPath /App/service.svc

Name                                                        Location
----                                                        --------
etwTracking                                                 MACHINE/WEBROOT/APPHOST/Default Web Site
serviceDebug                                                MACHINE/WEBROOT/APPHOST/Default Web Site/App
serviceMetadata                                             MACHINE/WEBROOT/APPHOST/Default Web Site/App

    Примечание

    Чтобы пример заработал, может потребоваться сменить политику выполнения с Restricted на RemoteSigned.

    Примечание

    Командлет Get-ServiceBehaviorConfigLocation принимает два параметра, задающих имя сайта (SiteName) и виртуальный путь (VirtualPath) целевой службы, и возвращает список действующих параметров конфигурации реакций на события, включающий расположения файлов конфигурации в формате путей IIS.

  2. Командлет также принимает конвейерный вывод из командлета Get-ASAppService в AppFabric. Помимо прочего, это позволяет использовать командлет со всеми службами, обнаруженными в указанной области, что демонстрируется в следующем примере:

    PS> Get-ASAppService -SiteName "Default Web Site" | 
      foreach-object {$service=$_; Get-ServiceBehaviorConfigLocation $service | 
      select-object @{Name="SiteName"; Expression={$service.SiteName}}, @{Name="VirtualPath"; Expression={$service.VirtualPath}}, "Name", "Location"}

SiteName                      VirtualPath                   Name                          Location
--------                      -----------                   ----                          --------
Default Web Site              /App/service.svc            serviceDebug                  MACHINE/WEBROOT/APPHOST/De...
Default Web Site              /App/service.svc            serviceMetadata               MACHINE/WEBROOT/APPHOST/De...
Default Web Site              /AnotherApp/HelpRequestT... etwTracking                   MACHINE/WEBROOT
Default Web Site              /AnotherApp/HelpRequestT... workflowInstanceManagement    MACHINE/WEBROOT
...

    Список служб, обнаруженных Get-ASAppService, конвейеризуется в Get-ServiceBehaviorConfigLocation, а для форматирования итоговых выходных данных используется предложение foreach. Обратите внимание, что при этом к исходному результату добавляются значения параметров SiteName и VirtualPath для каждой службы, что позволяет соотнести службы и параметры их реакций на события.

Удаление примера

  1. Просто закройте сеанс PowerShell, так как запуск примера не приводит к изменению каких-либо ресурсов на компьютере.

Демонстрации

Сценарий в примере содержит четыре раздела:

Инициализация

Первая часть сценария позволяет гарантировать, что загружены все необходимые компоненты. Сюда относится загрузка модуля командлетов AppFabric и библиотеки Microsoft.Web.Administration для чтения конфигурации IIS.

if ((Get-Command -Module ApplicationServer) -eq $null)
{
    Import-Module ApplicationServer
}

[System.Reflection.Assembly]::LoadFrom( "C:\windows\system32\inetsrv\Microsoft.Web.Administration.dll" ) | Out-Null

Функция командлета

Еще одна цель этого примера — демонстрация создания командлета в виде сценария, а не в коде. Get-ServiceBehaviorConfigLocation — это функция, определяющая командлет. В отличие от обычных функций в сценариях PowerShell, в ней содержатся разделы Param, Process и End для определения набора параметров командлета, логики обработки записей и логики очистки.

В нашем случае эта функция командлета отвечает только за нормализацию входных параметров и вызов функции GetBehaviorConfigLocationPerService, которая реализует основную логику выявления параметров конфигурации реакций на события.

Главная функция

Главная функция GetBehaviorConfigLocationPerService сначала открывает файл конфигурации в области службы. В примере используется API управляемого кода из библиотеки Microsoft.Web.Administration.dll, позволяющий читать файлы конфигурации из иерархии конфигурации IIS. Пример ищет все элементы <behavior> в соответствующей конфигурации службы и проходит по всем их дочерним элементам.

В функции используется хэш-таблица ($effectiveChildElementMap), в которой при этом проходе хранится список действующих параметров реакций на события. Содержимое хэш-таблицы меняется по мере того, как перечисление движется ниже по иерархии конфигурации; например, параметр X удален, если будет найден элемент <remove name=”X”/>. После завершения прохода итоговые значения из хэш-таблицы будут соответствовать действующей конфигурации реакций службы на события.

Вспомогательные функции

  • FindBehaviorElementsByName - находит все элементы <behavior> с атрибутом «name», соответствующим указанному имени.

  • IsClearTagPresent - определяет, есть ли в указанном элементе <behavior> вложенный элемент <clear>.

  • IsRemoveTagPresent - определяет, есть ли в указанном элементе <behavior> вложенный элемент <remove> с указанным атрибутом «name».

Known Issues/Limitations

  • Порядок следования элементов <remove> и <clear> относительно других элементов в одном и том же родительском элементе <behavior> нельзя определить с помощью API библиотеки Microsoft.Web.Administration. В примере предполагается, что элементы <remove> и <clear> следуют первыми.

  2011-12-05