controllando il nome di una pipe denominata quando si ospita l'associazione WC. net.pipe in IIS

StackOverflow https://stackoverflow.com/questions/1806430

  •  05-07-2019
  •  | 
  •  

Domanda

Ho un servizio accessibile tramite http e net.pipe. È ospitato in IIS 7 (Server 2008). Potrei ospitare diverse istanze di questo servizio per diversi clienti sulla stessa macchina e quindi l'HTTP è configurato con nomi host virtuali ecc. Tutto funziona perfettamente.

Pensavo che avrei fatto qualcosa di simile per la rete denominata pipe binding - usando una qualche forma di il "nomehost virtuale" dei clienti nell'indirizzo di base della pipe denominato, pertanto mi consente per accedere alle diverse istanze dei clienti con urne net.pipe diverse (mi rendo conto i nomi net.pipe sono URN non URL, quindi possono essere essenzialmente arbitrari ma Ho pensato di seguire un modello simile agli indirizzi HTTP).

Ecco il mio 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>

Tuttavia, quando si accede a WSDL per il servizio - sembra l'indirizzo di base per net.pipe essere ignorato da IIS. Invece ottengo il vero nome host della macchina e a net.pipe indirizzo URN che sembra essere stato completamente formattato da 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>

Senza alcun controllo sul modo in cui vengono formati i nomi net.pipe, non sarò in grado di discriminare tra le molteplici istanze del servizio clienti sulla macchina. Qualcuno ha qualche idea su come la rete denominata pipe binding URN può essere controllata all'interno dell'ambiente IIS?

(Faccio molto hosting standalone net.pipe durante i test (ovvero nuovo ServiceHost ())   quindi so che i miei binding net.pipe funzionano al di fuori di IIS e consentono il controllo   sopra l'esatta pipa denominata URN utilizzata)

Se i nomi non possono essere controllati all'interno di IIS, qualcuno ha qualche esperienza con l'hosting e l'accesso a più istanze separate del servizio net.pipe sulla stessa macchina?

È stato utile?

Soluzione

Questa è una vecchia domanda, ma ho pensato di aggiungere la mia risposta poiché avevo anche bisogno di una risposta per questo (e forse ci sono altri là fuori che ne hanno bisogno anche).

L'indirizzo di base di un servizio WCF ospitato da IIS è controllato da IIS e non può essere sovrascritto in web.config. Invece, puoi controllare gli indirizzi di base aggiornando le informazioni di associazione del sito IIS per il sito in cui stai ospitando il tuo servizio.

La maggior parte della documentazione che ho trovato online suggerisce l'utilizzo di * come configurazione di associazione per net.pipe. Ma se invece usi " virtualsite.com " come valore di configurazione dell'associazione, l'indirizzo di base dell'endpoint net.pipe sarà "virtualsite.com" anziché il nome della macchina.

Ecco un esempio che utilizza appcmd per configurare un sito in IIS con il binding net.pipe corretto:

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

Una nota su HostnameComparisonMode , non ha alcun effetto in IIS secondo MSDN :

  

Questi valori non hanno alcun effetto se utilizzati all'interno dell'ambiente di hosting Internet Information Services (IIS) o Windows Process Activation Service (WAS). In questi casi, WCF utilizza la modalità di confronto dei nomi host fornita dal sito Web IIS che ospita i servizi WCF.

Invece, devi usare il meccanismo che ho descritto sopra. Ho capito questo studiando come funziona l'associazione dei nomi host in HTTP per IIS. Sfortunatamente, non sono stato in grado di trovare alcuna documentazione ufficiale per questo scenario basato su IIS per altri trasporti WCF.

Altri suggerimenti

Sembra che la parte del nome host dell'URI venga ignorata e sostituita dall'implementazione basata su HostNameComparisonMode dell'associazione di canali. Puoi provare a cambiarlo in " Esatto " tramite la configurazione del servizio ...

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

  

NetNamedPipeBinding.HostnameComparisonMode   Il valore HostnameComparisonMode che indica se il nome host viene utilizzato per raggiungere il servizio durante la corrispondenza dell'URI. Il valore predefinito è StrongWildcard (), che ignora il nome host nella corrispondenza.

Vedi la sintassi di configurazione qui: http://msdn.microsoft.com/en-us/library/ms731291. aspx

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top