1

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. 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!

atconway
  • 20,624
  • 30
  • 159
  • 229
  • Well to add to this, I understand the cause of the single adress being shown. It has to do with the **mex** endpoints I am exposing. I probably only need a single meta data endpoint for the service, and the mex http endpoint will suffice (I think). Depending on what order I physically have the mex endpoints in my .config (which ever is 1st) determines which endpoint adress is displayed at the root in the WCF Test Client. – atconway May 25 '11 at 14:09

2 Answers2

0

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.

Sixto Saez
  • 12,610
  • 5
  • 43
  • 51
  • If you look at my configuration, I provided both mex endpoints: mexTcpBinding and mexHttpsBinding. How does it decide which one to present? – atconway May 24 '11 at 20:54
  • 1
    It picks it based on the transport of "URL" you give for the service. If it's http://.... You get that one **only**. – Sixto Saez May 24 '11 at 21:04
  • can you elaborate please a bit to help me. Right now I am presented with the "net.tcp" one in the test client, but I do not see where I set that in the "transport of URL" as you described. Can you point me in the proper direction please? – atconway May 25 '11 at 12:59
  • The "transport" refers to the http:// or net.tcp:// portion of the endpoint address. I think you are assuming that a single node in the WcfTestClient represents a single service (with all its endpoint) when in it only represents a **single endpoint**. Try this in the WcfTestClient, from the File menu select Add Service. In the dialog, enter your http://... endpoint URL and click OK. Next, again from the File menu select Add Service and enter the net.tcp://... endpoint address. After clicking OK, you should see two nodes in the My Service Project tree. Hope this clears things up. – Sixto Saez May 25 '11 at 13:19
  • I actually determined the root explination of my original question and I posted a comment up top. It has to do strictly with the **mex** endpoints in my configuration. It appears which ever is 1st in the .config is the one that is diplayed in the test client. There is no error having more than 1 mex endpoint but apparently, it still shows up as a single service choosing the address exposed via the 1st configured mex endpoint. – atconway May 25 '11 at 14:13
0

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

Community
  • 1
  • 1
atconway
  • 20,624
  • 30
  • 159
  • 229