controlando el nombre de una tubería con nombre cuando se aloja el enlace WCF net.pipe en IIS

Question

Tengo un servicio accesible a través de http y net.pipe. Se aloja en IIS 7 (Server 2008). Es posible que esté alojando diferentes instancias de este servicio para varios clientes en la misma máquina y, por lo tanto, el HTTP está configurado con nombres de host virtuales, etc. Todo está funcionando bien.

pensé que haría similar para la tubería de la red llamado vinculante - utilizando algún tipo de los clientes 'virtualhostname' en la dirección de base de canalización con nombre, por lo tanto, lo que me permite para acceder a los diferentes casos de clientes con diferentes urnas net.pipe (Me doy cuenta de los nombres net.pipe son URN's no URL así que pueden ser esencialmente arbitrarias pero pensé que seguiría un patrón similar a las direcciones HTTP).

Aquí es mi 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> 

Sin embargo, al acceder al WSDL para el servicio - la dirección base para el net.pipe parece para ser ignorado por IIS. En cambio, obtengo el nombre de host real de la máquina y una URN de dirección de red que parece haber sido formateada completamente por 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> 

sin control sobre la forma en que se forman los nombres net.pipe, no voy a ser capaz de discriminar entre las múltiples instancias de servicio al cliente en la máquina. ¿Alguien tiene alguna pista sobre cómo se puede controlar el URN obligatorio de enlace de canal dentro del entorno de IIS?

(hago un montón de net.pipe independiente de alojamiento durante la prueba (es decir, nueva ServiceHost()) así que sé que mis fijaciones net.pipe funcionan fuera del IIS, y no permiten el control sobre el tubo llamado exacta URN usado)

Si los nombres no se pueden controlar dentro de IIS, ¿alguien tiene alguna experiencia con el alojamiento y accediendo a múltiples instancias de servicio net.pipe en la misma máquina ?

Answer 1

Ésta es una vieja pregunta, pero pensé que me gustaría añadir mi respuesta ya que también necesitaba una respuesta para esto (y tal vez hay otros por ahí que lo necesito también).

La dirección base de un servicio WCF alojado en IIS está controlada por IIS y no puede anularse en web.config. En su lugar, puede controlar las direcciones base actualizando la información de enlace del sitio de IIS para el sitio en el que está hospedando su servicio.

La mayor parte de la documentación que encontré en línea sugiere usar * como configuración de enlace para net.pipe. Pero si en su lugar usa "virtualsite.com" como el valor de configuración de enlace, la dirección base de su punto final net.pipe será "virtualsite.com" en lugar del nombre de la máquina.

Aquí hay un ejemplo usando appcmd para configurar un sitio en IIS con la unión net.pipe correcta:

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

Una nota sobre HostnameComparisonMode, no tiene ningún efecto en IIS acuerdo con MSDN:

Estos valores no tienen ningún efecto cuando se usan dentro del entorno de alojamiento de Internet Information Services (IIS) o Servicio de activación de procesos de Windows (WAS). En esos casos, WCF utiliza el modo de comparación de nombre de host que proporciona el sitio web de IIS que aloja los servicios de WCF.

En su lugar, debe utilizar el mecanismo que describí anteriormente. Lo descubrí investigando cómo funciona el enlace de nombre de host en HTTP para IIS. Lamentablemente, no he podido encontrar ninguna documentación oficial para este escenario basado en IIS para otros transportes WCF.

Answer 2

Parece que la parte del nombre de host del URI se ignora y se reemplaza por la implementación en función del HostNameComparisonMode del enlace del canal. Usted puede intentar cambiar a la posición "exacta" a través de la configuración del servicio ...

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

NetNamedPipeBinding.HostnameComparisonMode El valor HostnameComparisonMode que indica si el nombre de host se utiliza para llegar al servicio cuando el juego URI. El valor predeterminado es StrongWildcard(), que ignora el nombre de host en la coincidencia.

Véase la sintaxis de configuración aquí: http://msdn.microsoft.com/en-us/library/ms731291.aspx