2010-11-12 14 views
11

Ich habe einen WCF-Dienst, der als Windows-Dienst gehostet wird. Wir möchten einen mex-Endpunkt unter der gleichen Adresse (aber mit einem Suffix '/ mex') aktivieren. Ich habe versucht, diese (erfolglos) mit folgenden Konfiguration zu tun:Wie erzwinge ich einen net.tcp mex-Endpunkt (mexTcpBinding), um an Port-Sharing teilzunehmen?

<system.serviceModel> 

    <services> 
    <service 
     name="MyCompany.MyService" 
     behaviorConfiguration="defaultServiceBehavior"> 

     <host> 
     <baseAddresses> 
      <add baseAddress="net.tcp://localhost"/> 
     </baseAddresses> 
     </host> 

     <endpoint 
     address="MyService" 
     binding="netTcpBinding" 
     contract="MyCompany.IMyService" 
     bindingConfiguration="netTcpBindingConfig" 
     /> 

     <endpoint 
     address="MyService/mex" 
     binding="mexTcpBinding" 
     contract="IMetadataExchange" 
     /> 

    </service> 
    </services> 

    <behaviors> 
    <serviceBehaviors> 
     <behavior name="defaultServiceBehavior"> 
     <serviceMetadata /> 
     </behavior> 
    </serviceBehaviors> 
    </behaviors> 

    <bindings> 
    <netTcpBinding> 
     <binding name="netTcpBindingConfig" portSharingEnabled="true" /> 
    </netTcpBinding> 
    </bindings> 

</system.serviceModel> 

Wenn es läuft, der Service Host ein AddressAlreadyInUseException beschweren, dass „Es gibt bereits einen Zuhörer auf IP-Endpunkt 0.0.0.0:808“ wirft. Dies ist für mich sinnvoll, da der Port-Sharing-Dienst diesen Port geöffnet hat, um den Endpunkt MyService zusammen mit anderen Diensten zu bedienen, die diesen Port auf diesem Rechner freigeben möchten.

So scheint es, dass der mex Endpunkt will 808. exlusive Zugriff auf Port I kann durch Zwicken des mex Endpunkt wie so dieses Problem umgehen:

<endpoint 
    address="net.tcp://localhost:818/MyService/mex" 
    binding="mexTcpBinding" 
    contract="IMetadataExchange" 
    /> 

Dies bedeutet, dass der mex Endpunkt nun ein eigen exklusiv Port hat . Der Nachteil dabei ist, dass jeder andere Dienst, der einen mex-Endpunkt bereitstellen möchte, auch einen eindeutigen Port für seinen mex-Endpunkt benötigt. Dies macht es sehr unberechenbar, wenn Sie nach mex Endpunkten suchen.

Gibt es eine Möglichkeit, den mex Endpunkt zur Teilnahme an Port-Sharing zu zwingen?

+0

Nur ein Gedanke: In bindingConfiguration = "netTcpBindingConfig" zum mex Endpunkt? –

+0

@Torben Ja, das habe ich ausprobiert. Wenn ich das tue, hat der mex-Endpunkt keine Problemfreigabe, aber es kann vollständig keine Metadaten erzeugen. –

Antwort

8

zwei Optionen:

  1. Die einfache Lösung: Ändern Sie die gesamte für den mex Punkt netTcpBinding Bindung und haben es Ihre bindingConfiguration wiederverwenden. mexTCPBinding soll nur eine Annehmlichkeit sein und ist optional. Wenn es nicht für Sie funktioniert, verwenden Sie es nicht.

  2. Der harte Weg: Sie können die mexTCPBinding ändern, um die Freigabe zu ermöglichen. Das einzige Beispiel, ich habe hier in Code zu sehen ist: http://blogs.msdn.com/b/drnick/archive/2006/08/23/713297.aspx

+0

Danke für Ihre Antwort. Ich habe versucht, mexTcpBinding zu netTcpBinding zu ändern, aber keine Würfel. Wenn ich das mache, startet der Dienst und beschwert sich nicht über das Teilen von Problemen (was cool ist), aber er antwortet nicht vollständig auf mex-Anfragen (was uncool ist). Vermutlich muss ich etwas anderes konfigurieren, wenn ich netTcpBinding verwende, das mir nicht bekannt ist? –

+0

@Damian hast du das jemals gelöst? Seltsamerweise sehen wir dieses Problem auf meinem lokalen Rechner, aber nicht in der Produktion –

+1

Der einfache Weg funktionierte für mich (Option 1). –