Script Windows PowerShell pour la détection de l'emplacement de la configuration du comportement de service

WCF 4.0 ajoute la possibilité de fusionner des comportements de service à partir de plusieurs fichiers de configuration figurant dans la hiérarchie de configuration. Cette fonctionnalité facilite la définition de comportements communs dans un fichier de configuration de haut niveau (par exemple, fichier web.config au niveau du site), et de définir des comportements supplémentaires dans des fichiers de configuration de niveau inférieur. L'exemple suivant illustre ce fonctionnement :

Site-level web.config

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

Application-level web.config

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

Un service WCF à l'intérieur de l'application et configuré pour utiliser « MyBehavior » hérite effectivement des configurations serviceDebug/serviceMetadata et etwTracking. Pour plus d'informations sur la configuration de comportement fusionnée, consultez les rubriques Behavior Merge in WCF 4.0 Configuration (https://go.microsoft.com/fwlink/?LinkId=194422) (en anglais) et .NET Configuration Merge Default Behavior (https://go.microsoft.com/fwlink/?LinkId=194423) (en anglais).

Malgré sa flexibilité, la configuration de comportement fusionnée crée une confusion parce que la configuration de comportement effective du service peut différer de ce qui est défini dans le fichier web.config local. Cet exemple montre comment écrire un script PowerShell dans un formulaire de cmdlet, qui analyse la configuration de comportement de service et indique les emplacements des fichiers de configuration contenant les paramètres effectifs.

Conditions préalables

Il est préférable que l'utilisateur soit familiarisé avec les scripts Windows PowerShell et les cmdlets d'AppFabric.

L'exemple nécessite les conditions préalables suivantes :

• PowerShell v2 est installé.

• L'installation d'AppFabric par défaut a été effectuée.

Emplacement et fichiers de l'exemple

Les exemples de fichiers inclus sont les suivants :

• Readme.mhtml

• Code\detectServiceBehaviorConfigLocation.ps1

Configuration et exécution de l'exemple

1. L'exemple suivant montre comment exécuter la cmdlet de script à partir d'une console 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
   

   Notes

   Il se peut que vous deviez modifier la stratégie d'exécution de Restricted en RemoteSigned pour que l'exemple fonctionne.

   Notes

   La cmdlet Get-ServiceBehaviorConfigLocation prend deux paramètres qui spécifient les valeurs SiteName et VirtualPath d'un service cible, puis renvoie une liste de valeurs de configuration de comportement effectifs qui comprend des emplacements de fichier de configuration au format de chemin d'accès IIS.

2. La cmdlet accepte également la sortie de la cmdlet Get-ASAppService d'AppFabric via le pipeline. Cela permet notamment à la cmdlet de fonctionner avec tous les services découverts dans une étendue spécifiée, comme le montre l'exemple suivant :

   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
   ...
   

   Une liste de services trouvés par Get-ASAppService est canalisée vers Get-ServiceBehaviorConfigLocation et la clause foreach est utilisée pour mettre en forme le résultat final. Notez qu'elle ajoute les valeurs SiteName et VirtualPath de chaque service au résultat original de façon à ce que les services et leurs paramètres de comportement puissent être corrélés.

Suppression de l'exemple

1. Fermez simplement la session PowerShell car l'exécution de cet exemple ne modifie aucune ressource de l'ordinateur.

Démontre

Le script de cet exemple comprend quatre sections :

Initialisation

La première partie du script vérifie que toutes les dépendances sont chargées. Cela inclut le chargement du module de cmdlet d'AppFabric et la bibliothèque Microsoft.Web.Administration pour la lecture de la configuration d'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

Fonction de cmdlet

Un autre objectif de cet exemple est de montrer comment créer une cmdlet dans un script plutôt que dans un code. La fonction Get-ServiceBehaviorConfigLocation est celle qui définit la cmdlet. À la différence d'une fonction normale des scripts PowerShell, elle contient les éléments Param, Process et End pour définir respectivement les ensembles de paramètres de cmdlet, la logique pour le traitement d'enregistrement et la logique pour le nettoyage.

Dans notre cas, cette fonction de cmdlet est uniquement responsable de la normalisation du paramètre d'entrée et appelle la fonction GetBehaviorConfigLocationPerService qui contient la logique principale pour la détection de l'emplacement des paramètres de configuration du comportement.

La fonction principale

La fonction principale GetBehaviorConfigLocationPerService commence par ouvrir le fichier de configuration sur l'étendue du service. L'exemple utilise une API de code managé dans Microsoft.Web.Administration.dll pour lire les fichiers de configuration dans la hiérarchie de configuration d'IIS. Il recherche tous les éléments <behavior> dont la configuration de service correspond, puis énumère tous les éléments enfants de chacun d'eux.

La fonction maintient une table de hachage ($effectiveChildElementMap) qui contient la liste de paramètres de comportement effectifs durant l'énumération. Le contenu de la table de hachage évolue à mesure que l'énumération progresse dans la hiérarchie de configuration. Par exemple, un paramètre X sera supprimé si un élément <remove name=”X”/> est observé. Une fois l'énumération terminée, les valeurs finales dans la table de hachage correspondront à la configuration de comportement effective du service.

Fonctions d'assistance

• FindBehaviorElementsByName - recherche tous les éléments <behavior> dont l'attribut « name » correspond au nom spécifié.

• IsClearTagPresent - détermine si l'élément <clear> est présent sous l'élément <behavior> spécifié.

• IsRemoveTagPresent - détermine si l'élément <remove> avec l'attribut « name » correspondant est présent sous l'élément <behavior> spécifié.

Known Issues/Limitations

• L'API Microsoft.Web.Administration ne peut pas déterminer l'ordre de l'élément <remove>/<clear> par rapport aux autres éléments sous le même élément <behavior> parent. L'exemple part du principe que l'élément <remove>/<clear> apparaît en première position.

  2011-12-05