contrôler le nom d'un canal nommé lors de l'hébergement de la liaison net.pipe WCF dans IIS

Question

J'ai un service accessible via http et net.pipe. Il est hébergé dans IIS 7 (Server 2008). Il se peut que je héberge différentes instances de ce service pour plusieurs clients sur le même ordinateur. Le protocole HTTP est donc configuré avec des noms d’hôte virtuels, etc. Tout fonctionne correctement.

Je pensais que je ferais la même chose pour le filet nommé pipe binding - en utilisant une forme de le 'virtualhostname' des clients dans l'adresse de base du tube nommé, me permettant ainsi pour accéder aux différentes instances client avec différentes urnes net.pipe (je réalise les noms de net.pipe ne sont pas des URL d'URN, ils peuvent donc être essentiellement arbitraires, mais Je pensais que je suivrais un modèle similaire aux adresses HTTP).

Voici mon web.config

<service name="Administration" behaviorConfiguration="AdministrationBehavior">
    <endpoint address="" binding="wsHttpBinding" bindingConfiguration="normalWsBinding" contract="IAdministration" />
    <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" />
    <endpoint address="" binding="netNamedPipeBinding" bindingConfiguration="normalNetNamedPipeBinding" contract="IAdministration" />
    <endpoint address="mex" binding="mexNamedPipeBinding" contract="IMetadataExchange" />
    <host>
      <baseAddresses>
        <add baseAddress="http://virtualhostname.com/service" />
        <add baseAddress="net.pipe://virtualhostname.com/administration/service" />
      </baseAddresses>
    </host>
</service>

Cependant, lors de l'accès au WSDL du service - l'adresse de base du net.pipe semble être ignoré par IIS. Au lieu de cela, je reçois le vrai nom d’hôte de la machine et un URN net.pipe qui semble avoir été entièrement formaté par IIS.

<wsdl:port name="NetNamedPipeBinding_IAdministration" binding="tns:NetNamedPipeBinding_IAdministration">
   <soap12:address location="net.pipe://realhostname/service/Administration.svc"/>
   <wsa10:EndpointReference>
       <wsa10:Address>net.pipe://realhostname.com/service/Administration.svc</wsa10:Address>
       <Identity>
          <Spn>host/realhostname.com</Spn>
       </Identity>
   </wsa10:EndpointReference>
</wsdl:port>

Sans aucun contrôle sur la façon dont les noms net.pipe sont formés, je ne pourrai pas discriminer entre les multiples instances de service client sur la machine. Quelqu'un sait-il comment le réseau nommé URN de liaison de tuyau nommé peut-il être contrôlé dans l’environnement IIS?

(Je fais beaucoup d’hébergement autonome net.pipe lors des tests (par exemple, nouveau ServiceHost ())   donc je sais que mes liaisons net.pipe fonctionnent en dehors d’IIS et permettent le contrôle   l’URN du canal nommé exact utilisé)

Si les noms ne peuvent pas être contrôlés dans IIS, est-ce que quelqu'un a une expérience quelconque avec hébergement et accès à plusieurs instances de service net.pipe distinctes sur le même serveur machine?

Answer 1

C’est une vieille question, mais j’ai pensé que j’ajouterais ma réponse, car j’avais également besoin d’une réponse à cette question (et peut-être que d’autres ont également besoin de cette réponse).

L'adresse de base d'un service WCF hébergé par IIS est contrôlée par IIS et ne peut pas être remplacée dans web.config. Au lieu de cela, vous pouvez contrôler les adresses de base en mettant à jour les informations de liaison de site IIS pour le site sur lequel vous hébergez votre service.

La plupart de la documentation que j'ai trouvée en ligne suggère d'utiliser * comme configuration de liaison pour net.pipe. Mais si vous utilisez plutôt & virtual; virtualsite.com " En tant que valeur de configuration de liaison, l'adresse de base de votre point de terminaison net.pipe sera "virtualsite.com". plutôt que le nom de la machine.

Voici un exemple d'utilisation de appcmd pour configurer un site dans IIS avec la liaison net.pipe appropriée:

%windir%\system32\inetsrv\appcmd.exe set site "Default Web Site" -+bindings.[protocol='net.pipe',bindingInformation='virtualhostname.com']

Une remarque à propos de HostnameComparisonMode , elle n'a pas d'effet dans IIS selon MSDN :

  

Ces valeurs n'ont aucun effet lorsqu'elles sont utilisées dans l'environnement d'hébergement Internet Information Services (IIS) ou WAS (Windows Process Activation Service). Dans ces cas, WCF utilise le mode de comparaison de nom d’hôte fourni par le site Web IIS hébergeant les services WCF.

Au lieu de cela, vous devez utiliser le mécanisme que j'ai décrit ci-dessus. J'ai compris cela en examinant le fonctionnement de la liaison de nom d'hôte dans HTTP pour IIS. Malheureusement, je n'ai trouvé aucune documentation officielle concernant ce scénario basé sur IIS pour d'autres transports WCF.

Answer 2

Il semble que la partie du nom d'hôte de l'URI soit ignorée et remplacée par l'implémentation basée sur le nom d'hôte (HostNameComparisonMode) de la liaison de canal. Vous pouvez essayer de le remplacer par " Exact " via la configuration du service ...

http://msdn.microsoft.com /en-us/library/system.servicemodel.netnamedpipebinding.hostnamecomparisonmode.aspx

  

NetNamedPipeBinding.HostnameComparisonMode   La valeur HostnameComparisonMode qui indique si le nom d'hôte est utilisé pour atteindre le service lors de la mise en correspondance de l'URI. La valeur par défaut est StrongWildcard (), qui ignore le nom d’hôte dans la correspondance.

Voir la syntaxe de configuration ici: http://msdn.microsoft.com/en-us/library/ms731291. aspx