Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>This thread's answer contains the answer to my original question:</p> <p><a href="https://stackoverflow.com/questions/2399865/multiple-base-addresses-and-multiple-endpoints-in-wcf">Multiple Base Addresses and Multiple Endpoints in WCF</a></p> <p>I was confused that I could create a <em>single</em> 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) <em>both</em> 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.</p> <p>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 <em>all</em> 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).</p> <p>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.</p> <p>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 <em>all</em> 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.</p> <p>A little write up on this:</p> <p><strong>Exposing Multiple Binding Types For The Same Service Class In WCF:</strong><br/> <a href="http://allen-conway-dotnet.blogspot.com/2011/09/exposing-multiple-binding-types-for.html" rel="nofollow noreferrer">http://allen-conway-dotnet.blogspot.com/2011/09/exposing-multiple-binding-types-for.html</a></p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload