Intellisense when editing Service Bus configuration files? Yes please!

  • Article

The problem

The setup of Windows Azure  AppFabric SDK adds the elements reported in the table below to the configuration contained in the the machine.config files under the following folders:

  • %windir%\Microsoft.NET\Framework\v4.0.30319\Config
  • %windir%\Microsoft.NET\Framework64\v4.0.30319\Config
 <?xml version="1.0" encoding="UTF-8"?><configuration> ... <system.serviceModel>  <extensions>   <behaviorExtensions>    ...    <!-- Windows Azure AppFabric Service Bus Endpoint Behaviors -->    <add name="connectionStatusBehavior"          type="Microsoft.ServiceBus.Configuration.ConnectionStatusElement, Microsoft.ServiceBus, ..." />    <add name="transportClientEndpointBehavior"          type="Microsoft.ServiceBus.Configuration.TransportClientEndpointBehaviorElement, ..." />    <add name="serviceRegistrySettings"          type="Microsoft.ServiceBus.Configuration.ServiceRegistrySettingsElement, Microsoft.ServiceBus, ..." />   </behaviorExtensions>   <bindingElementExtensions>    ...    <!-- Windows Azure AppFabric Service Bus Transport Binding Elements -->    <add name="tcpRelayTransport"          type="Microsoft.ServiceBus.Configuration.TcpRelayTransportElement, Microsoft.ServiceBus, ..." />    <add name="httpRelayTransport"          type="Microsoft.ServiceBus.Configuration.HttpRelayTransportElement, Microsoft.ServiceBus, ..." />    <add name="httpsRelayTransport"          type="Microsoft.ServiceBus.Configuration.HttpsRelayTransportElement, Microsoft.ServiceBus, ..." />    <add name="onewayRelayTransport"          type="Microsoft.ServiceBus.Configuration.RelayedOnewayTransportElement, Microsoft.ServiceBus, ..." />   </bindingElementExtensions>   <bindingExtensions>     ...    <!-- Windows Azure AppFabric Service Bus Relay Binding -->    <add name="basicHttpRelayBinding"          type="Microsoft.ServiceBus.Configuration.BasicHttpRelayBindingCollectionElement, Microsoft.ServiceBus, ..." />    <add name="webHttpRelayBinding"          type="Microsoft.ServiceBus.Configuration.WebHttpRelayBindingCollectionElement, Microsoft.ServiceBus, ..." />    <add name="ws2007HttpRelayBinding"          type="Microsoft.ServiceBus.Configuration.WS2007HttpRelayBindingCollectionElement, Microsoft.ServiceBus, ..." />    <add name="netTcpRelayBinding"          type="Microsoft.ServiceBus.Configuration.NetTcpRelayBindingCollectionElement, Microsoft.ServiceBus, ..." />    <add name="netOnewayRelayBinding"          type="Microsoft.ServiceBus.Configuration.NetOnewayRelayBindingCollectionElement, Microsoft.ServiceBus, ..." />    <add name="netEventRelayBinding"          type="Microsoft.ServiceBus.Configuration.NetEventRelayBindingCollectionElement, Microsoft.ServiceBus, ..." />   </bindingExtensions>  </extensions>  ... </system.serviceModel> ...</configuration>

 

However, configuring WCF extensions in the machine.config is not sufficient to enable Intellisense on the relay bindings and endpoint behaviors contained in the AppFabric Service Bus Class Library when you edit the configuration file (web.config, app.config) of an application that exposes or consume services in the cloud. To scope the problem, let’s assume for a moment that you create an on-premises or cloud application that exposes a service via the AppFabric Service Bus. Your service will surely expose one or more endpoints based on one of the relay bindings supplied out-of the-box by the AppFabric Service Bus Class Library. However, when you try to use Visual Studio to define the configuration of any relay bindings and endpoint behaviors provided by the Service Bus, IntelliSense is unable to recognize these elements. For example, the picture below shows what happens when you try to define the configuration for the WebHttpRelayBinding and the TransportClientEndpointBehavior. In a nutshell, you cannot rely on IntelliSense to compose and validate your configuration file using a syntax-driven approach. Moreover, Visual Studio raises a warning for each unrecognized element within your configuration. Now, I don’t know about you, but when I compile my projects I cross my fingers until the build process completes.When I see the Rebuild All succeeded message on the left-bottom corner of Visual Studio I heave a sigh of relief, but in order to attain the maximum level of happiness, my Errors and Warnings lists must be empty!

Before   

The solution

Now, the XSD used by Visual Studio IntelliSense is stored under "%ProgramFiles(x86)%\Microsoft Visual Studio 10.0\Xml\Schemas\DotNetConfig.xsd". Hence, I decided to extend this XML schema file to add Intellisense for the bindings and behaviors provided by AppFabric Service Bus. BizTalk Editor came in handy  for this purpose because I could use its cut and paste capabilities to accelerate the task. I created an entry for each relay binding or endpoint behavior defined within the AppFabric Service Bus Class Library as you can see in the image below:

DotNetConfig

After customizing the DotNetConfig.xsd, IntelliSense works as expected as shown in the following picture.

After

Conclusions

Utilizing IntelliSense rather than cut and paste or memorization makes it more likely I will enter settings correctly and also gets rid of all of those unsightly warnings! Here you can download the Visual Studio 2010 DotNetConfig.xsd customized for the Azure Service Bus. Please drop me a line if you find any problems or improvements to suggest. Thanks!

Review by: Christian Martinez and Tim Wieman.

Comments

  • Anonymous
    October 08, 2011
    Intellisense would be nice as I ran into same issue.

  • Anonymous
    November 11, 2013
    Unfortunately editing the .net config xsd file with BizTalk editor leads to a very large number of other changes in the file. Loading the file in Visual Studio's file compare the entire file is marked as 'red' for change. Encoding is changed, schemas.microsoft.com/.../2003 is added to the namespaces, many end of lines are changed from "/> to " /> (a space is inserted). While these changes are probably harmless, it makes it difficult to distinguish the intentional changes. Another thing: DotNetConfig.xsd no longer exists in Visual Studio 2012. Instead there is one xsd per .NET version. So I am guessing now the changes need to be applied to every version schema file.

  • Anonymous
    November 11, 2013
    Hi David It comes without saying that the article was originally writtern for Visual Studio 2010. As you notices in your comment, the DotNetConfig.xsd no longer exists in Visual Studio 2012, so yes, I think you are right, I think that the changes should be applied to every schema file. If you happen to try it out, please let me know! Ciao Paolo

  • Anonymous
    March 27, 2014
    Hi Paolo,      Are you in a position to encourage the DevDiv team to produce a supported solution to this issue? If not, could you recommend someone we could talk to? Given this "bug / work item" has existed for several years now. It costs MSFT in both PSS support costs as well as lost opportunity (I could provide evidence of both) You'd think it would be worthwhile to spend a few hours to resolve. I realize there is MS Connect & UserVoice, however I'm feeling a little disillusioned by both, as it take s long time to type up a recommendation, often they get many votes only to eventually get closed as "won't fix" without any explanation.

  • Anonymous
    March 27, 2014
    Hi David I understand your frustration. I'll make sure to forward your feedback to the Visual Studio team. Ciao Paolo