Above The Cloud

In my last post (only this morning) I talked about an extra endpoint appearing in the WCF Test Client being the result of a rogue entry in Machine.Config, placed there when you install the .Net Services SDK.

I just noticed that this endpoint also appears elsewhere. Consider this screen capture:

This is the ‘Edit WCF Configuration’ screen screen that you can use to specify client and service endpoints in your App.Config / Web.Config. The only problem is that I have not defined any client end points : only service ones. And as you can see, the name is ‘sb’ which is the same name given to the end point defined in machine.config.

Funnily enough you can actually delete the endpoint from here. This causes the following to appear in your app.config:

<client>
  <remove contract=”IMetadataExchange” name=”sb” />
</client>

As a result, the endpoint no longer appears in your application. But it is still there when you run the WCF Test Client, so it still seems the only definitive way to remove it is in the machine.config file.

I came across something interesting today. I was using WCF for something completely unrelated to Azure and .Net Services. Whenever I ran the WCF Test Client (which hosts your service for you) I would get an error: the test client would attempt to add an IMetadata endpoint, even if you don’t have one defined!

There is also a popup message when the client first opens indicating that states:

The contract ‘IMetadataExchange’ in client configuration does not match the name in service contract

Its not a huge deal; you can ignore the error and still proceed to test your service. However it was worth investigating a little further.

I came across this thread that seemed to describe exactly my problem, however it related purely to Biztalk SDK which I definately did not have installed (I even double checked to ensure it wasn’t installed as part of another SDK such as Win2008 SDK, VS SDK, etc). Did I have Biztalk SDK installed somewhere that I couldn’t find?

I proceeded to investigate the machine.config file, found in your C:\Windows\Microsoft.NET\Framework\v2.0.50727\CONFIG directory. Under the <client> section I had quite a lot of interesting stuff, but as expected the IMetadataExchange endpoint was defined there:

<endpoint address=”" binding=”netTcpRelayBinding” bindingConfiguration=”metadataExchangeRelayBinding”
    contract=”IMetadataExchange” name=”sb” />

This was definately the culprit, I knew because the name (sb) matched that in the WCF Test Client. I knew from the article that the solution was to remove the whole <client> section, but I really wanted to know what had put it there. Looking further down I ran across some lines similar to this:

<extension type=”Microsoft.ServiceBus.Description.TcpRelayTransportBindingElementImporter, Microsoft.ServiceBus, Version=0.14.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35″ />

This is when I had my lightbulb moment. The reference to ‘Microsoft.ServiceBus’ gave it all away. Yes, Biztalk is an Enterprise Service Bus, and no doubt lots of its assemblies are probably along these lines, but there is something else that evolved from Biztalk: Biztalk Services… which is now known as ‘.Net Services’.

Summary

In summary, if you see this error in your WCF Test Client, you will know that it is because you either have Biztalk SDK or .Net Services SDK installed. However I am unsure if it is safe for your Azure projects if you remove the <client> section from your machine.config. I’ll put the feelers out to see what I can find out.