Why does the WCF Test Client tool only display a single endpoint baseAdress for multiple endpoints when debugging?

I have the following configuration for my Windows Service hosted WCF service:

    <services>      
  <service name="MyService" behaviorConfiguration="MyServiceBehavior">        
    <endpoint address="" 
              binding="netTcpBinding" 
              bindingConfiguration="WindowsClientOverTcp"
              name="WindowsClientOverTcp" 
              contract="IMyService" />
    <endpoint address=""
              binding="wsHttpBinding"
              bindingConfiguration="WindowsClientOverHttps"
              name="WindowsClientOverHttps"
              contract="IMyService">         
    </endpoint>

    <endpoint address="mex" 
              binding="mexTcpBinding" 
              contract="IMetadataExchange" />
    <endpoint address="mex"
              binding="mexHttpsBinding"
              contract="IMetadataExchange" />
    <host>
      <baseAddresses>
        <add baseAddress="https://MyMachine:8250/Services/MyService/Https" />
        <add baseAddress="net.tcp://MyMachine:8250/Services/MyService/tcp" />
      </baseAddresses>
    </host>        
  </service>  

1st: Everything works. 开发者_C百科However I have a question. When starting to debug the service in VS.NET 2010 and the "WCF Test Client" tool appears, only the single "net.tcp://MyMachine:8250/Services/MyService/tcp" address is displayed at the top of the tree navigation, and both endpoints displayed as child elements (WindowsClientOverTcp & WindowsClientOverHttps). Now both base addresses are consumable and usable so there is no major issue. However, why is it only showing the single address in the tool? I thought it might be the order displayed in the .config so I switched them around but that didn't change anything.

Anyone know why both base addresses do not display in the WCF Test Client tool when having a single service exposing multiple endpoints?

Thanks!

The WcfTestClient is presenting the service based on the transport of the MEX endpoint you are giving it. If you give the HTTP based endpoint it'll present that one, give the NET.TCP one and that's all it presents.

If you look at WSDL generated by the service, you'll find only the endpoint description for that transport. It's not that WcfTestClient that is limited, its the WSDL.

This thread's answer contains the answer to my original question:

Multiple Base Addresses and Multiple Endpoints in WCF

I was confused that I could create a single service with multiple endpoints and multiple mex endpoints to still behave like 2 services both implementing the same contract. However I do not like this because when you consume my service (either via net.tcp or https) both endpoint configurations are added to the client. I think what I am going to do is create 2 different service configurations, each still implementing the same contract but just with unique names and bindings.

The WCF Test client did a good job of representing exactly what was occuring, based on only reading the single mex endpoint, but yet still exposing both main service endpoints. I don't really like the fact the client gets all the binding configurations when using multiple bindings within a single service (it's not a bad thing, just not the way I intended because a client in my scenario will not switch between binding types mid-way through a single application).

So in conclusion I will break out the configuration to expose (2) services with separate endpoints and their own mex endpoints, so the consuming client (and WCF Test Client) will get only a single endpoint configuration for each address consumed. In order to do this though I have to make some modifications, because 2 service configurations can not point to the same "Service Name" which is the actual class implementing the contract. In my scenario since both services will still implement the same contract I need a way to give them unique names. I added 2 more contracts that inherit from the original contract (1 for each service) and 2 new classes that inherit from the main implementation class. They really don't do anything but create separate placeholders for the WCF service configuration. Then each service configuration has the name of the new class allowing them to be distinct.

And now with this configuration, the WCF Test Client shows each main service endpoint as its own entity. This again does not have to be done if you don't mind the client getting all the endpoint configurations for a single service, but in my case I wanted distinct service addresses, with their single downloaded configuration, yet still implementing the same overall contract.

A little write up on this:

Exposing Multiple Binding Types For The Same Service Class In WCF:
http://allen-conway-dotnet.blogspot.com/2011/09/exposing-multiple-binding-types-for.html