controlling the name of a named pipe when hosting WCF net.pipe binding in IIS

Question

I have a service accessible via http and net.pipe. It is being hosted in IIS 7 (Server 2008). I may be hosting different instances of this service for several customers on the same machine and hence the HTTP is setup with virtual hostnames etc. This is all working fine.

I thought I would do similar for the net named pipe binding - using some form of the customers 'virtualhostname' in the named pipe base address, therefore allowing me to access the different customer instances with different net.pipe urns (I realize the net.pipe names are URN's not URL's so they can be essentially arbitrary but I thought I would follow a similar pattern to the HTTP addresses).

Here is my 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>

However, when accessing the WSDL for the service - the base address for the net.pipe seems to be ignored by IIS. Instead I get the real hostname of the machine, and a net.pipe address URN that seems to have been formatted entirely by 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>

With no control over the way net.pipe names are formed, I will not be able to discriminate between the multiple customer service instances on the machine. Does anyone have any clue as to how the net named pipe binding URN can be controlled within the IIS environment?

(I do a lot of standalone net.pipe hosting during testing (i.e. new ServiceHost()) so I know that my net.pipe bindings do work outside of IIS, and do allow control over the exact named pipe URN used)

If the names can't be controlled within IIS - does anyone have any experience with hosting and accessing multiple separate net.pipe service instances on the same machine?

Answer 1

This is an old question, but I figured I'd add my answer since I also needed an answer for this (and maybe there are others out there who need it too).

The base address of an IIS-hosted WCF service is controlled by IIS and cannot be overridden in web.config. Instead, you can control the base addresses by updating the IIS site binding information for the site you're hosting your service in.

Most of the documentation I found online suggests using * as the binding configuration for net.pipe. But if you instead use "virtualsite.com" as the binding configuration value, the base address of your net.pipe endpoint will be "virtualsite.com" rather than the machine name.

Here is an example using appcmd to configure a site in IIS with the correct net.pipe binding:

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

One note about HostnameComparisonMode, it has no effect in IIS according to MSDN:

These values have no effect when used inside of the Internet Information Services (IIS) or Windows Process Activation Service (WAS) hosting environment. In those cases, WCF uses whatever hostname comparison mode is provided by the IIS Web Site hosting the WCF services.

Instead, you have to use the mechanism I described above. I figured this out by investigating how hostname binding works in HTTP for IIS. Unfortunately, I've not been able to find any official documentation for this IIS-based scenario for other WCF transports.