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.
Notes
Les exemples sont fournis à titre éducatif uniquement. Ils ne sont pas destinés à être utilisés dans un environnement de production et n'ont pas été testés à cet usage. Microsoft ne fournit aucune assistance technique pour ces exemples.
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
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/AppNotes
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.
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
- 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.
2012-03-05