Forward Thinking

Error "An extension of name '' already appears in extension collection" with .Net 4.5 RC?

PiyushJo — Tue, 19 Jun 2012 05:44:00 GMT

Do you happen to see any of the following errors when you upgrade your machine to .Net 45?

System.Configuration.ConfigurationErrorsException:An extension of name ' udpTransport ' already appears in extension collection. Extension names must be unique.

System.Configuration.ConfigurationErrorsException:An extension of name 'netHttpBinding' already appears in extension collection. Extension names must be unique.

In .NET 4.5, WCF has added UdpBinding (UDP) and NetHttpBinding (WebSockets) as standard bindings for the benefit of customers. If you happen to use any of .NET 4.0 WCF samples which help in implementing a custom UDP transport or netHttp transport binding element (old custom binding sample unrelated to WebSockets) and migrate your machine to .NET 4.5 Release candidate (RC) build, you may see an error like above. We acknowledge this as an issue and this should get automatically fixed for you in RTM build. Meanwhile here are some steps to temporarily work around this issue:

Step 1.
If you have a configuration file for your WCF client/service which fails, open and search for any binding element extension that you have configured with name “udpTransport” or “netHttpBinding”.

Step 2.
Rename it to something which is not “udpTransport” or “netHttpBinding”.

Step 3.
Restart your application / service. This should fix the problem.

BEFORE:

<system.serviceModel>
<extensions>

<bindingElementExtensions>
<add name="udpTransport" type="MyCustomTransport.UdpTransportElement, MyCustomTransportLibrary" />
</bindingElementExtensions>

<bindingElementExtensions>
         <add name="netHttpBinding" type="MyCustomTransport.NetHttpTransport, MyCustomTransportLibrary "/>
</bindingElementExtensions>
  …

</system.serviceModel>

AFTER:

<system.serviceModel>
<extensions>

<bindingElementExtensions>
<add name="myCustomUdpTransport" type="MyCustomTransport.UdpTransportElement, MyCustomTransportLibrary" />
</bindingElementExtensions>

<bindingElementExtensions>
         <add name="myCustomNetHttpBinding" type="MyCustomTransport.NetHttpTransport, MyCustomTransportLibrary" />
</bindingElementExtensions>
  …

</system.serviceModel>

Thanks.

Windows Azure Service Bus – Push based programming approach

PiyushJo — Wed, 02 Nov 2011 06:13:59 GMT

While working with Azure Service Bus, either with the queue or with the topic/subscription, you need to explicitly write code to pull messages from the queue or from the subscription. A typical pattern looks like the following:

Code Snippet
 // Create a SB queue
QueueDescription queue = CreateQueue();
 
// Create a factory and client to talk to this queue
MessagingFactory factory = MessagingFactory.Create(ServiceUri, TokenProvider);
QueueClient client = factory.CreateQueueClient(queue.Path);
 
// Send a message to the queue
string requestMessage = "Hello World!";
client.Send(new BrokeredMessage(requestMessage));
 
// Receive the message from the queue
BrokeredMessage responseQueueMessage = client.Receive();
string responseMessage = responseQueueMessage.GetBody<string>();
 

Note how you have to write code in line 13,14 to receive the messages from the queue. Programing with topic/subscription follow similar pattern in how you need to pull messages from the subscription client.

Now what if the queue is constantly receiving messages that you need to process or if you want to use a session full communication with the queue or if you want to do custom processing of messages based on some message content or if you want to carry out an async operation when you receive the message? You may be able to program these scenarios but the number of lines and the complexity of the code increases.

If you think about it – receiving a message and doing “something” with it is exactly what a WCF service does so wouldn’t it be cool if there is an ability to start up a WCF service which will listen for messages received by the queue/subscription and do whatever that you want to do with this message? This is essentially what I meant by the title – Push based programing approach. This means that you don’t have to worry about constantly pulling the messages from the queue – you define a service method (or methods as we will see) to do whatever you want to do when the message is received and the WCF service, like a humble servant, will do it for you.

Today we uploaded a Nuget package (containing source and sample) which introduce a set of extension methods on the QueueClient and SubscriptionClient which take care of starting up a WCF service instance and then we follow a convention based approach to route the queued messages to the appropriate service method which takes care of handling its processing.

The package walks you through a set of ten scenarios – first five of which explore Service Bus as it is today and the remaining five build on the push based programming model to show how easy it has become now to program against Service Bus.

Scenario 1 – We enumerate all the queues in your namesapce using NamespaceManager.GetQueues() method:

A typical output will look like the following:

Scenario 2 - We enumerate all the topics in your namespace using NamespaceManager.GetTopics() method:

A typical output will look like the following:

Scenario 3 - We show how you can send and receive messages to a queue using a QueueClient formed from a MessagingFactory:

Code Snippet
 // Create a SB queue
QueueDescription queue = CreateQueue();
 
// Create a factory and client to talk to this queue
MessagingFactory factory = MessagingFactory.Create(ServiceUri, TokenProvider);
QueueClient client = factory.CreateQueueClient(queue.Path);
 
// Send a message to the queue
string requestMessage = "Hello World!";
client.Send(new BrokeredMessage(requestMessage));
Console.WriteLine("Message sent to the queue - '{0}' ", requestMessage);
 
// Receive the message from the queue
BrokeredMessage responseQueueMessage = client.Receive();
string responseMessage = responseQueueMessage.GetBody<string>();
Console.WriteLine("Message received from the queue - '{0}' ", responseMessage);
 
// Cleanup
client.Close(); 
factory.Close();
 

This example shows how you program against Service Bus queue right now. A typical output will look like the following:

Scenario 4 - We show how you can send messages to a topic and receive messages via a subscription client:

Code Snippet
 string topicName = "news";
string subscriptionName = "mySubscription";
 
// Delete the topic if it already exists
if (NamespaceManager.TopicExists(topicName))
{
    NamespaceManager.DeleteTopic(topicName);
}
 
// Create the topic 
Console.WriteLine("Creating new topic - '{0}'", topicName);
TopicDescription topic = NamespaceManager.CreateTopic(topicName);
 
// Create a subscription
Console.WriteLine("Creating new subscription - '{0}'", subscriptionName);
SubscriptionDescription subs = NamespaceManager.CreateSubscription(topic.Path, subscriptionName);
 
// Create a factory to talk to the topic & subscription
MessagingFactory factory = MessagingFactory.Create(ServiceUri, TokenProvider);
 
// Create a topic client to talk to this topic
TopicClient topicClient = factory.CreateTopicClient(topic.Path);
 
// Send a message to the topic
string requestMessage = "Hello World!";
Console.WriteLine("Message sent to the topic - '{0}' ", requestMessage);
topicClient.Send(new BrokeredMessage(requestMessage));
 
// Create a subscription client to receive messages
SubscriptionClient subscriptionClient = factory.CreateSubscriptionClient(topic.Path, subs.Name);
 
// Receive the messages from the subscription
BrokeredMessage responseQueueMessage = subscriptionClient.Receive();
string responseMessage = responseQueueMessage.GetBody<string>();
Console.WriteLine("Message received from the subscription - '{0}' ", responseMessage);
 
// Cleanup
subscriptionClient.Close();
topicClient.Close(); 
factory.Close();
 

Again – this example shows how you program against Service Bus topic/subscription currently. A typical output will look like the following:

Scenario 5 - We show the WCF integration – how you can create a WCF service which will listen on a Service Bus endpoint and how you can relay messages using a WCF client to this WCF service via the Azure Service Bus.

Code Snippet
 NetMessagingBinding binding = new NetMessagingBinding();
 
// Start up the Echo WCF service listening via Azure Service Bus
ServiceHost host = new ServiceHost(typeof(EchoService));
ServiceEndpoint echoServiceEndpoint
    = host.AddServiceEndpoint(typeof(IEchoService), binding, QueueAddress);
echoServiceEndpoint.Behaviors.Add(new TransportClientEndpointBehavior(TokenProvider));
host.Open();
Console.WriteLine("WCF service up and running, listening on {0}", QueueAddress);
 
// Create a WCF channel factory and client to send message to the Azure Service Bus
ChannelFactory<IEchoService> factory = new ChannelFactory<IEchoService>
    (binding, new EndpointAddress(QueueAddress));
factory.Endpoint.Behaviors.Add(new TransportClientEndpointBehavior(TokenProvider));
IEchoService proxy = factory.CreateChannel();
 
// Send messages to the service
string requestMessage = "Hello World";
proxy.Echo(requestMessage);
Console.WriteLine("Message sent to the queue - '{0}' ", requestMessage);
 
// clean up the client and service
factory.Close();
host.Close();
 

Nothing new here - a typical output will look like the following:

Scenario 6 – With scenario 6 onwards we start harnessing the power of the Service Bus push based programming library.

We start with a simple scenario applying this new approach to receive messages.

Code Snippet
 // Create a ServiceBus queue. 
QueueDescription queue = CreateQueue();
 
// Create a factory and client to talk to this queue
MessagingFactory factory = MessagingFactory.Create(ServiceUri, TokenProvider);
QueueClient client = factory.CreateQueueClient(queue.Path);
 
// Use the extension method to pass in a delegate 
//  which will handle all messages received by the queue
client.StartListener(message => 
    Console.WriteLine("Message received from the queue - {0}", message.GetBody<string>()));
 
// Send a message to the queue
string helloMessage = "Hello World!";
client.Send(new BrokeredMessage(helloMessage));
Console.WriteLine("Message sent to the queue - '{0}' ", helloMessage);
 
// Send another message to the queue
string byeMessage = "Bye World!";
client.Send(new BrokeredMessage(byeMessage));
Console.WriteLine("Message sent to the queue - '{0}' ", byeMessage);
 
// clean up the client and service
client.StopListener(); 
client.Close();
factory.Close();
 

Note line 10 – here we are using the StartListener extension method on QueueClient which takes in a delegate which will handle the messages received by the queue henceforth. A typical output will look like the following:

Scenario 7 – We expand on the previous scenario by explicitly providing a service type which will be responsible for handling the incoming messages to the queue. We also make the scenario interesting by attaching an Action property to each BrokeredMessage we are sending to the queue. The idea is to route messages to different service methods based on this Action property of the incoming message.

Code Snippet
 class MyActionOrientedEchoService
{
    [OnMessage(Action = "EchoOnce")]
    public void EchoOnce(BrokeredMessage msg)
    {
        Console.WriteLine("Message received by EchoOnce method");
        string messageBody = msg.GetBody<string>();
        Console.WriteLine(messageBody);
    }
 
    [OnMessage(Action = "EchoTwice")]
    public void EchoTwice(BrokeredMessage msg)
    {
        Console.WriteLine("Message received by EchoTwice method");
        string messageBody = msg.GetBody<string>();
        Console.WriteLine(messageBody);
        Console.WriteLine(messageBody);
    }
}
 

Code Snippet
 // Create a ServiceBus queue. 
QueueDescription queue = CreateQueue();
 
// Create a factory and client to talk to this queue
MessagingFactory factory = MessagingFactory.Create(ServiceUri, TokenProvider);
QueueClient client = factory.CreateQueueClient(queue.Path);
 
// Use the extension method to start the WCF service 
//  which will handle the queued messages based on its Action property
client.StartListener(typeof(MyActionOrientedEchoService));
 
string requestMessage = "Hello World!";
// Send message to the queue - to the EchoOnce operation
BrokeredMessage message = new BrokeredMessage(requestMessage);
message.SetAction("EchoOnce");
Console.WriteLine("Message '{0}' sent with '{1}' action", requestMessage, "EchoOnce");
client.Send(message);
 
// Send message to the queue - to the EchoTwice operation
BrokeredMessage anotherMessage = new BrokeredMessage(requestMessage);
anotherMessage.SetAction("EchoTwice");
Console.WriteLine("Message '{0}' sent with '{1}' action", requestMessage, "EchoTwice");
client.Send(anotherMessage);
 
// Cleanup
client.StopListener(); 
client.Close();
factory.Close();
 

In line 10 – we are again using the StartListener extension method to start up the service of type ‘MyActionOrientedEchoService’. Note the following points about the service:

the service doesn’t need to implement any interface or be marked with a ServiceContract attribute
the service has two methods marked with the OnMessage attribute. This is a new attribute defined in the sample. All queued messages will be directed to a method decorated with this attribute.
The regular convention though, which is automatically understood, is to use a public method named OnReceivedMessage returning void and accepting a single parameter of type BrokeredMessage which will be used to dispatch the incoming messages. In the absence of such a method, the dispatching is done to a public method with return type void and which accepts a parameter of type BrokeredMessage only if there is exactly one such method. Of course – OnMessage attribute is used to override such conventions.
In this scenario – we want to do custom processing based on received messages and hence we define two service methods each with OnMessage attribute and using the Action parameter which will help in directing the message to the correct operation.

In line 15 and 21, we are using the SetAction extension method to add an ‘action’ property to the BrokeredMessage and this will be used to direct the message to the suitable service method.

A typical output will look like the following:

Scenario 8 – We integrate sessions in this scenario. We see how we can easily spawn up different service instances which will handle the incoming queued messages based on the SessionId we attach to the brokered message.

Code Snippet
 class MySessionfulService
{
    public void OnReceiveMessage(BrokeredMessage msg)
    {
        Console.WriteLine("Received Message - {0}, Received by service - {1}",
            msg.GetBody<string>(), this.GetHashCode());
    }
 
    public void OnError(Exception e)
    {
        Console.WriteLine("Error occurred");
        Console.WriteLine(e.Message);
    }
}
 

Code Snippet
 // Create a sessionful queue
QueueDescription queue = NamespaceManager.CreateQueue
    (new QueueDescription(QueueName) { RequiresSession = true });
 
// Create a factory and client to talk to this queue
MessagingFactory factory = MessagingFactory.Create(ServiceUri, TokenProvider);
QueueClient client = factory.CreateQueueClient(queue.Path);
 
// Use the extension method to start up the WCF service 
// which will process the sessionful queued messages received by the queue
client.StartListener(typeof(MySessionfulService), requiresSession: true);
 
string helloMessage = "Hello World!";
string byeMessage = "Bye World!";
 
// Start sending messages to the queue
// Session 1
BrokeredMessage message1 = new BrokeredMessage(helloMessage);
message1.SessionId = "1";
client.Send(message1);
 
BrokeredMessage message2 = new BrokeredMessage(byeMessage);
message2.SessionId = "1";
client.Send(message2);
 
// Session 2
BrokeredMessage message3 = new BrokeredMessage(helloMessage);
message3.SessionId = "2";
client.Send(message3);
 
BrokeredMessage message4 = new BrokeredMessage(byeMessage);
message4.SessionId = "2";
client.Send(message4);
 
// Cleanup
client.Close();
factory.Close();
 

In line 2, we are ensuring that the ServiceBus queue enables sessions and correspondingly in line 11, we are starting up the WCF service listener enabling sessions. Note that in the MySessionfulService implementation we are sticking to the convention of using the method with the signature – void OnReceivedMessage (BrokeredMessage msg) which will handle all incoming messages. Also note another convention based method void OnError(Exception ex) – this is used to handle all the errors arising out of handling the queued messages. Again – for handling errors - we will look for a method which conforms to this signature if an OnError method does not exist. Internally, we are simply registering an IErrorHandler that redirects Exceptions to the error handler. This means that anything that is bubbled up to the IErrorHandler by ServiceModel will make its way to the error handler

A typical output will look like the following:

Note that I can also add a service behavior specifying the InstanceContextMode of my WCF service if I so desire – by default it is PerSession but I can change it to PerCall or Single to influence how my service method processes the incoming messages.

Scenario 9 – We extend the example to show how you can use the same WCF based push approach to receive messages for a subscription from a topic.

Code Snippet
 // Create the topic 
Console.WriteLine("Creating new topic - '{0}'", topicName);
TopicDescription topic = NamespaceManager.CreateTopic(topicName);
 
// Create a subscription
Console.WriteLine("Creating new subscription - '{0}'", subscriptionName);
SubscriptionDescription subs = NamespaceManager.CreateSubscription(topic.Path, subscriptionName);
 
// Create a factory to talk to the topic & subscription
MessagingFactory factory = MessagingFactory.Create(ServiceUri, TokenProvider);
 
// Create a topic client to talk to this topic
TopicClient topicClient = factory.CreateTopicClient(topic.Path);
 
// Create a subscription client to retrive messages
SubscriptionClient subscriptionClient = factory.CreateSubscriptionClient(topic.Path, subs.Name);
 
// Start the WCF service which will receive the messages sent to the topic
subscriptionClient.StartListener(typeof(MyQueuedMessageHandlerService)); 
 
// Send a message to the topic
string requestMessage = "Hello World!";
Console.WriteLine("Message sent to the topic - '{0}' ", requestMessage);
topicClient.Send(new BrokeredMessage(requestMessage));
 
// Cleanup
subscriptionClient.StopListener(); 
subscriptionClient.Close();
topicClient.Close();
factory.Close();
 

All the overloads which exist on the QueueClient, as we saw above, are also available on the SubscriptionClient. A WCF service will be started up in a similar way to handle all messages received by this subscription.

A typical output will look like the following:

Scenario 10 – We show how you can use the same approach to carry out an async operation at the receipt of the queued message.

Code Snippet
 class MyAsyncEchoService
{
    public Task DoComplexTaskAsync(BrokeredMessage message)
    {
        Console.WriteLine("Async method called");
        return Task.Factory.StartNew(() => 
        { 
            // Do some complex task
            Console.WriteLine("Starting complex task at {0}", DateTime.Now.ToString());  
            Thread.Sleep(5000);
            Console.WriteLine("Completing complex task at {0}", DateTime.Now.ToString());  
        });
    }
}
 

Code Snippet
 // Create a ServiceBus queue. 
QueueDescription queue = CreateQueue();
 
// Create a factory and client to talk to this queue
MessagingFactory factory = MessagingFactory.Create(ServiceUri, TokenProvider);
QueueClient client = factory.CreateQueueClient(queue.Path);
 
// Use the extension method to start the WCF service 
//  which will handle the queued messages based on its Action property
client.StartListener(typeof(MyAsyncEchoService));
 
// Send message to the queue
string requestMessage = "Hello World!";
BrokeredMessage message = new BrokeredMessage("Hello World!");
client.Send(message);
Console.WriteLine("Message sent to the queue - '{0}' ", requestMessage);
 
// Cleanup
client.StopListener(); 
client.Close();
factory.Close();
 

The service implementation is the only interesting part otherwise the sample is identical to what we have seen in earlier scenarios. Note how the method takes in a BrokeredMessage and returns a Task.

A typical output will look like the following:

Thank you!

Special thanks to Youssef who was instrumental in developing this library.

Calling a WCF service from a Metro application – service deployed in Azure

PiyushJo — Tue, 01 Nov 2011 00:24:41 GMT

Alright then – lets move the WCF service to the cloud!

Scenario – This is another take on my “Sunny or Cloudy” metro application we developed in my first post. We will make it visually appealing! And how do I plan to do that? Have you noticed how in the TV forecast, they show you weather information overlapped on a map of the area – something like the following:

Well, we will use the same concept and deploy a WCF service in Azure which given a zip code, will give us an area map and the weather information about it. Following is the screenshot from our finished metro client application:

I passed the zip code of Manhattan area of New York city and got back the area’s Bing maps link and the weather information which I am showing overlapped on the map. (It surely has cleared up there after snowing over the weekend – a surprise snow storm early in October itself!)

WCF service :

The WCF service, which we will be deploying in Azure, will act as an aggregator of information will be developed in .net 4.0 so that we can deploy it in Azure. Following diagram shows its architecture:

Metro client application users will enter a zip code.
This zip code will be sent to the WCF service deployed in Azure. The service will be deployed in a web role with BasicHttpBinding and hence accessible over http and we will configure it with TransportWithMessageCredential security mode so that we can use username/password credentials to authenticate the metro client.
This WCF service will use HttpClient library (This is a NuGet package for the HtpClient functionality for .Net 4.0, HttpClient is only available in .Net 4.5) to make calls to the Bing Maps REST APIs to fetch a link to the map of the area.
The Azure WCF service will also call out to an external ASMX weather service to get the weather details. Notably – this weather webservice returns back an image url describing the weather conditions which we will use to overlay on the area map. This is the ‘sunny’ weather image link in the metro client screenshot above on top of the Manhattan area map.

1. So we start with an Azure Cloud application project and add a WCF Service WebRole. You need to download the “Windows Azure Tools for Microsoft Visual Studio” for this.

2. Next, we define the service and the data contract for the Azure WCF service:

Code Snippet
 [ServiceContract]
public interface IWeatherInfo
{
    [OperationContract]
    WeatherInfo GetWeatherInfo(string inputZip);
}
 
[DataContract]
public class WeatherInfo
{
    [DataMember]
    public string Locality { get; set; }
    
    [DataMember]
    public string WeatherDescription { get; set; }
    
    [DataMember]
    public string WeatherImageUri { get; set; }
    
    [DataMember]
    public string MapImageUri { get; set; }
}
 

The service contract is straightforward – it takes a zip code and returns a data contract consisting of the members we will use in the metro client to display the area and weather information.

3) To make calls to the Bing Maps REST APIs – I have chosen to use the HttpClient so we need to download the HttpClient NuGet reference.

4) And to make calls to the external weather web service – http://wsf.cdyne.com/WeatherWS/Weather.asmx, we need to add a service reference to it.

5) I’ll let you explore the implementation of the WCF service by downloading the sample code from below. Few highlights of the code though -

a) The code below shows how we are creating a WCF client proxy to talk to the weather ASMX webservice and making a call to it using the zip code passed to the service method call:

Code Snippet
 WeatherInfo returnResults = new WeatherInfo(); 
WeatherWebservice.WeatherSoapClient weatherProxy = new WeatherWebservice.WeatherSoapClient("WeatherSoap");
WeatherWebservice.WeatherReturn weatherResults = new WeatherWebservice.WeatherReturn();
 
// Call the weather web service to get weather information 
weatherResults = weatherProxy.GetCityWeatherByZIP(inputZip);
 

b) The code below shows how we are using the HttpClient API to make a call to the Bing Maps REST API. You will need to register with the Bing Maps (http://www.bingmapsportal.com/) to get a developer key to use the maps APIs.

To get the area map url - I needed to make a couple of these REST calls – one to get the latitude/longitude of the area given a zip code and the next to get the a maps image url feeding it the latitude/longitude I retrieved from the first call.

Code Snippet
 // Use the Web APIs HttpClient to access Bing Maps REST service to get the city map 
string bingMapsKey = "<enter your bing maps key";
 
HttpClient client = new HttpClient();
string bingMapsPointDataQuery = String.Format
    ("http://dev.virtualearth.net/REST/v1/Locations?countryRegion=US&postalCode={0}&o=xml&key={1}", 
        inputZip, bingMapsKey);
HttpResponseMessage bingMapsPointsData = client.Get(bingMapsPointDataQuery);
 

6. Lets configure security on our Azure WCF service:

a. Open up the WCF service web.config and add an https protocol mapping -

Web.config Snippet
 <protocolMapping>
  <remove scheme="http" />
  <add binding="basicHttpBinding" bindingConfiguration="secureBinding" scheme="https" />
</protocolMapping>
 

We are removing the http access of the WCF service and restricting it to https.

b. Next configure the binding to use TransportWithMessageCredential security mode and UserName client credential type. This will allow us to pass a username/password from the metro client to authenticate.

Web.config Snippet
   <binding name="secureBinding">
    <security mode="TransportWithMessageCredential">
      <message clientCredentialType="UserName" />
    </security>
  </binding>
</basicHttpBinding>
 

Code Snippet
 <behaviors>
  <serviceBehaviors>
    <behavior name="">
      <serviceMetadata httpsGetEnabled="true" />
 

We are also configuring httpsGetEnabled on the serviceMetadata behavior to allow us to expose the service metadata over https exclusively.

c. Next, we will add a custom userNamePasswordValidator so that we can validate the credentials passed by the Metro client.

Code Snippet
 public class MyCustomUserNamePasswordValidator : UserNamePasswordValidator
{
    public override void Validate(string userName, string password)
    {
        if (userName != "myAzureUsername" || password != "myAzurePassword")
        {
            throw new FaultException("Invalid credentials"); 
        }
    }
}
 

This is just a hard coded credentials check for demo purpose! Next we need to wire this custom username/password validator to the service by adding a serviceCredentials service behavior.

Web.config Snippet
     <!-- Adding custom username password validator -->
    <serviceCredentials>
      <userNameAuthentication userNamePasswordValidationMode="Custom" 
                              customUserNamePasswordValidatorType="WCFServiceWebRole.MyCustomUserNamePasswordValidator, WCFServiceWebRole" />
    </serviceCredentials>
  </behavior>
</serviceBehaviors>
 

7. Now the fun part – configuring certificates which can be used by our Azure WCF service for the configured transport security. We will use self-signed certificates for this purpose. http://msdn.microsoft.com/en-us/library/cc949067.aspx is an excellent link which walks you through this – showing how to create a root certificate authority certificate (Step 1) which you will then need to install in the Trusted Root Certificate Authority of the Win8 machine (Step 2) from where the Metro client makes its call and finally creating the service certificate from the root certificate (Step 3). This service certificate will be used for SSL communication between the client and the server. Step 4 in the above walkthrough is not needed as it is IIS specific.

Make sure that you are substituting the <machineName> with the name where you will be deploying your WCF service in Azure (e.g. in my case it was piyushjoWeatherService.cloudapp.net)

This is required because this certificate is going to be used by our WCF service deployed in Azure at this host name and therefore when the Metro client will attempt to establish an SSL connection with this service, WCF client will ensure that the subject name of the certificate with which the WCF service it is talking to is configured matched exactly with the hostname it is using to make the service call. This is identical to how you configure if your service was hosted on premise – where you need to make sure that the certificate is issued to a subject name matching the machine name where the service is hosted.

For actual production deployment you would go to a certificate authority like VeriSign to provide you a certificate with the subject name where you will be deploying your service so no need to create these self-signed certificates. You will also not need the Step 2 from above link to deploy the root certificate in the Trusted Root authority store because trusted root certificates from reputed authorities like VeriSign are already installed there.

8. Finally we add the certificate to the WCF web role and configure the Azure WCF service web role to expose an https endpoint and use the certificate we just created to provide SSL security for this https endpoint.

9. Lastly we create a package for the Azure WCF service and deploy it to an Azure production deployment along with the certificate. The final deployment will look like this (depending on the instances you have requested)

[Note that you can consider using the MSDN subscriber benefits for deploying in Azure if you are an MSDN member - http://www.microsoft.com/windowsazure/msdn-benefits/]

WCF client :

So once you have deployed your WCF service in Azure, you need to create the Metro client to connect to this service. You will use the Add Service Reference (ASR) functionality for this. There is no difference from what I have showed in my previous post – you just pass the reference to your deployed Azure WCF service while generating the service reference – e.g. I used the reference - https://piyushjoweatherservice.cloudapp.net/WeatherService.svc to my Azure deployed service.

[Note that this service is no longer running in Azure so you will have to point the sample code to your own deployment]

Interesting parts of the generated service reference are the GetEndpointAddress method which references the Azure WCF service:

Code Snippet
 private static System.ServiceModel.EndpointAddress GetEndpointAddress(EndpointConfiguration endpointConfiguration) {
            if ((endpointConfiguration == EndpointConfiguration.BasicHttpBinding_IWeatherInfo)) {
                return new System.ServiceModel.EndpointAddress("https://piyushjoweatherservice.cloudapp.net/WeatherService.svc");
            }
            throw new System.InvalidOperationException(string.Format("Could not find endpoint with name \'{0}\'.", endpointConfiguration));
        }
 

and the GetBindingForEndpoint method which is configuring the TransportWithMessageCredential security mode on the binding

Code Snippet
 private static System.ServiceModel.Channels.Binding GetBindingForEndpoint(EndpointConfiguration endpointConfiguration) {
            if ((endpointConfiguration == EndpointConfiguration.BasicHttpBinding_IWeatherInfo)) {
                System.ServiceModel.BasicHttpBinding result = new System.ServiceModel.BasicHttpBinding();
                result.AllowCookies = true;
                result.Security.Mode = System.ServiceModel.BasicHttpSecurityMode.TransportWithMessageCredential;
                return result;
            }
            throw new System.InvalidOperationException(string.Format("Could not find endpoint with name \'{0}\'.", endpointConfiguration));
        }
 

Note that you don’t have to change anything in the generated service reference. ASR functionality will generate the correct service reference for you.

And that’s it – you are ready to consume your WCF service. The metro client code looks like the following:

Code Snippet
 private async void Button_Click(object sender, RoutedEventArgs e)
{
    AzureWeatherSvcRef.WeatherInfoClient proxy
        = new AzureWeatherSvcRef.WeatherInfoClient();
 
    proxy.ClientCredentials.UserName.UserName = "myAzureUsername";
    proxy.ClientCredentials.UserName.Password = "myAzurePassword";
 
    AzureWeatherSvcRef.WeatherInfo info = await proxy.GetWeatherInfoAsync(inputZip.Text);
    WeatherReasults.Text = String.Format("{0} - {1}", info.Locality, info.WeatherDescription);
    MapImage.Source = new BitmapImage(new Uri(info.MapImageUri));
    WeatherImage.Source = new BitmapImage(new Uri(info.WeatherImageUri)); 
}
 

Here I am creating a proxy to my WCF service in line 3, attaching the credentials recognized by my Azure deployed WCF service in line 6 and calling the service in line 9. As you would have gathered – considering this is a metro client application, we absolutely do not want to block the UI thread while making this call – and so we are calling the service asynchronously (note the async keyword on the button click event handler and the await keyword while making the call). Once the service returns results and populates the WeatherInfo object, I am using it to assign values to my various UI elements.

And that was that! Let me know if any part of this walkthrough needs any further clarification and I’ll add to that.

Thanks.

Azure Wcf Service
Metro Client

Calling a WCF service from a Metro application – cross machine scenario

PiyushJo — Sat, 22 Oct 2011 06:58:26 GMT

So you have developed your WCF service to be consumed by your Metro client application – you would likely have done the development on your local machine. What is the next step [before we move to Azure ] ? You will probably take your service and deploy it on another machine either for testing cross machine scenario or you are just going with on-premise hosting.

So what is interesting here? Well, start up the metro client and try to connect to the WCF service. Does it work?

If you are calling the service asynchronously which is how you should be doing it – you will see the metro client just hang waiting for the service to respond. While calling synchronously you will see an Aggregate exception throw almost instantly with the inner exception being – “There was no endpoint listening at /.svc">/.svc">http://<serverName>/<service>.svc that could accept the message. This is often caused by an incorrect address or SOAP action. See InnerException, if present, for more details.". with innermost exception of – “{"An attempt was made to access a socket in a way forbidden by its access permissions XXX.XXX.XXX.XXX:80"}”

To fix this - what you need to do is to add an additional capability to your metro application – “Home/Work networking” – this enables metro applications access services in your domain network. More information here.

Hope it helps!

Thanks.

What’s new in WCF 4.5 – Tooltips & IntelliSense

PiyushJo — Fri, 21 Oct 2011 01:43:47 GMT

So continuing on my WCF 4.5 posts - and expanding on the configuration simplicity theme - I'll dedicate this one to the simplification efforts we have done to ease configuring WCF services.

Tooltips support and extended IntelliSense

Many folks have a tough time while dealing with the numerous knobs we have in the WCF configuration system. All these different configuration settings while providing immense flexibility, also add to the complexity - developers need to know each knob and also remember which knob is for what purpose. So we thought what can we do to help the developers here - we looked around and saw editors like the C# editor in Visual Studio providing nice little features of Tooltips and IntelliSense which boost developer productivity substantially and we decided to adopt them for WCF Xml configuration as well!

Tooltips support is now available for WCF configuration elements and its properties in the Xml configuration editor:

The tooltip message is the same as what shows up in the description of the configuration element in the WCF configuration schema documentation in MSDN. I will admit that some of the MSDN descriptions do lack in clarity and seem ambiguous but we are always improving the documentation on MSDN.

There is some existing IntelliSense support for WCF configuration already however in Visual Studio 2011, we have extended this further to cover some of the scenarios where we think this will be super useful.

Lets walk through how you configure when you have created a service and operation contract and written your WCF service implementing them. You open up the .config file and if you are the brave one – you start editing it by hand!

Starting with the service tag – we now auto populate the available services:

OK – that’s done – then you start adding configuring the service:

a. starting with the binding -

b. or the contract

c. Or any named service or endpoint behavior which you already created:

As you saw – we now auto populate all of it for you to just click and select – no more copying/pasting or typing it by hand. This will eliminate all those crazy spelling mistakes where you thought you named it EndpointBehavior but it was actually EndpointBehaviour and you were pulling out your hairs about why the service was behaving in unexplained manner!

Not only this – even if you decide to ignore the IntelliSense and make mistakes – you will see validation instantly lighting up and preventing you from doing this:

And if you don’t listen to it – it will also show up in the Warnings on the debug window:

Note on the internal working -

When a user opens up the XML editor to modify the WCF service configuration file, it reads the dotNetConfig.xsd document, which ships with Visual Studio (located here - " \\Program Files (x86)\Microsoft Visual Studio 11.0\Xml\Schemas\DotNetConfig.xsd) and this file contains the .NET framework configuration schema. The XML editor uses this schema to perform validation (adding those red/blue squiggles) and provide tooltips. The tooltips information is extracted from the xs:annotation\xs:documentation tag:

Since this schema definition file is picked for all application templates in Visual Studio when you are modifying the xml configuration file – this means that you will get the added IntelliSense and Tooltips support whenever you are dabbling in configuration under system.serviceModel section in Visual Studio 2011, be it WCF service application template or some console application while creating self-hosted service.

Thank you!

WCF in Metro apps – supported functionality

PiyushJo — Wed, 19 Oct 2011 05:35:00 GMT

I wanted to do this quick post to outline the supported functionality in terms of commonly used APIs for WCF in Metro apps. I am not listing each and every included API in this post but just listing the top level ones which are commonly used to give you an idea. Let us know if you think there is something obvious which is missing and which you would eventually want to see in the final release. You can also drill down into the included APIs by using your favorite disassembler (for me it is Reflector!) on the reference assemblies here - C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETCore\v4.5

Bindings -

BasicHttpBinding
NetTcpBinding
NetHttpBinding
CustomBinding

Binding elements -

BinaryMessageEncodingBindingElement
TextMessageEncodingBindingElement
ConnectionOrientedTransportBindingElement
SslStreamSecurityBindingElement
WindowsStreamSecurityBindingElement
TcpTransportBindingElement
Http(s)TransportBindingElement
TransportSecurityBindingElement

Encoding -

Text, Binary

Security modes -

None, Transport, TransportWithMessageCredential, TransportCredentialOnly (for BasicHttpBinding)

ClientCredentialType -

None, Basic, Digest, Negotiate, Ntlm, Windows

Transfer Mode -

Buffered, Streamed, StreamedRequest, and StreamedResponse

Serializers -

DataContractSerializer, DataContractJsonSerializer, XmlSerializer

Miscellaneous -

ChannelFactory

DuplexChannelFactory

CallbackBehavior

Thanks!

Calling a WCF service from a Metro application – adding security

PiyushJo — Tue, 11 Oct 2011 07:58:00 GMT

[Updated for Win8/Dev11 Beta]

This is an extension to my earlier post - http://blogs.msdn.com/b/piyushjo/archive/2011/10/10/calling-a-wcf-service-from-a-metro-application.aspx where I did a walkthrough of calling a WCF service hosted locally on the same machine from a C# Metro client application. In this post, I’ll take you through how to add security.

As you will remember, I had a Picture REST service with webHttpBinding and a ViewCount SOAP service.

Below is a refresher on how to add security to the binding and configuring the respective service hosts with these bindings.

Code Snippet
// Add service endpoint & webHttp behavior
WebHttpBinding webBinding = new WebHttpBinding(WebHttpSecurityMode.TransportCredentialOnly);
webBinding.Security.Transport.ClientCredentialType = HttpClientCredentialType.Windows;
pictureServiceHost.AddServiceEndpoint(typeof(IPictureService), webBinding, String.Empty)
    .EndpointBehaviors.Add(new WebHttpBehavior() { HelpEnabled = true });

Code Snippet
// Add service endpoints
BasicHttpBinding basicBinding = new BasicHttpBinding(BasicHttpSecurityMode.TransportCredentialOnly);
basicBinding.Security.Transport.ClientCredentialType = HttpClientCredentialType.Windows;
viewCountServiceHost.AddServiceEndpoint(typeof(IViewCount), basicBinding, String.Empty);

I am going to use my domain credentials and so I have configured my bindings with SecurityMode of TransportCredentialOnly and HttpClientCredentialType of Windows.

Once you have made the above changes to the service, you need to start up the service host and export metadata for the SOAP service so that we can add service reference to it. When you have completed the Add Service Reference (ASR) action from the metro client application, you will see the following now modified GetBindingForEndpoint method generated on the client (in Reference.cs file, if you do ‘Show all files’ on the added service reference) which as you can see is already configured for security.

Code Snippet
private static System.ServiceModel.Channels.Binding GetBindingForEndpoint(EndpointConfiguration endpointConfiguration) {
            if ((endpointConfiguration == EndpointConfiguration.BasicHttpBinding_IViewCount)) {
                System.ServiceModel.BasicHttpBinding result = new System.ServiceModel.BasicHttpBinding();
                result.AllowCookies = true;
                result.Security.Mode = System.ServiceModel.BasicHttpSecurityMode.TransportCredentialOnly;
                result.Security.Transport.ClientCredentialType = System.ServiceModel.HttpClientCredentialType.Windows;
                return result;
            }
            throw new System.InvalidOperationException(string.Format("Could not find endpoint with name \'{0}\'.", endpointConfiguration));
        }

If you are doing this from a non-metro client then equivalents of lines 5 and 6 get generated in xml configuration but since there is no xml styled configuration for metro application, the WCF ASR experience is intelligent enough to generate the equivalent code.

The above code configuration will enable the proxy to call the SOAP web service providing default domain credentials and you do not have to write any additional piece of code other than instantiating the proxy as we were already doing.

Code Snippet
// Call the SOAP web service to get details - e.g. view count
PhotoService.ViewCountClient proxy = new PhotoService.ViewCountClient();

That takes care of the SOAP service.

Now for the REST service, we need to configure our HttpClient, which we were using to access the service, to pass the credentials. Here is how you do it:

Code Snippet
HttpClientHandler handler = new HttpClientHandler();
handler.UseDefaultCredentials = true;
HttpClient client = new HttpClient(handler); 

You need to instantiate an HttpClientHandler object, configure it to use the default credentials and provide it to the HttpClient so that HttpClient knows that when it gets back an HTTP status code 401 from the service with request for credentials, it needs to pass the default domain credentials.

And finally, before running the metro client, don’t forget to enable the “Default Windows Credentials” capability which will allow the metro client to retrieve the required domain credentials:

I have modified my REST and SOAP service methods to print the domain credential name passed to the service (using OperationContext.Current.ServiceSecurityContext.WindowsIdentity.Name) so you know that the credentials are getting passed correctly!

Sample code attached:

Thank you!

Calling a WCF service from a Metro application

PiyushJo — Mon, 10 Oct 2011 00:44:00 GMT

[Updated for Win8/Dev11 Beta]

In this post, we will do a walkthrough of creating a metro application calling a WCF service hosted locally on the same machine. Note that this is an application development/debug scenario only before you deploy your service on a different machine and this will not be supported for deployed metro applications.

First – a bit of an overview about the sample application. The C# metro application will be a photo viewing application with two user scenarios:

1) Users can view pictures from a source (here the source is going to be a WCF REST service and the metro application will use the new HttpClient to connect to the REST service)

2) Users can then ‘click’ or ‘tap‘ (if you are using the touch interface) a picture to get the view count on it (this View count will come from a WCF SOAP service and the metro application will use BasicHttpBinding to receive and send updates on the view count of the picture)

I am going to use a console application to host both my Picture REST service and ViewCount SOAP service.

Picture REST service

Code Snippet
[ServiceContract]
interface IPictureService
{
[WebGet]
string[] GetPictureIds();
[WebGet]
Stream GetPicture(string PictureId);
}

The service has two WebGet methods – one returning all the unique identifiers of the pictures available with the service and the other returning a stream representing the picture associated with a PictureId. [We are assuming that the service already has a collection of fantastic pictures and doesn’t need anyone uploading more to it ]

The implementation of the service is simple though GetPicture implementation might interest you a bit -

Code Snippet
public Stream GetPicture(string PictureId)
{
FileStream file = new FileStream(PicturesCollection[PictureId].ToString(), FileMode.Open);
WebOperationContext.Current.OutgoingResponse.ContentType = "image/jpeg";
return file; 
}

Here I am returning a picture image file whose path is determined by the PictureId and setting the content type of the response to ‘image/jpeg’. This is interesting because this will enable any client which knows how to process this content type to automatically do so without any other client programming required – e.g. if you call this REST service from the browser providing a valid picture id as recognized by this service, the service will return and the browser will automatically display the image file. You can also modify the ContentType to return data of any other format depending on your service.

Hosting the service is akin to what we always do:

Code Snippet
// ***************   PICTURE REST SERVICE   ***************   
string pictureServiceAddress = "http://localhost/PictureService";
WebServiceHost pictureServiceHost = new WebServiceHost(typeof(PictureService), new Uri(pictureServiceAddress));
// Add service endpoint & webHttp behavior
pictureServiceHost.AddServiceEndpoint(typeof(IPictureService), new WebHttpBinding(), String.Empty)
    .EndpointBehaviors.Add(new WebHttpBehavior() { HelpEnabled = true });
 
pictureServiceHost.Open();

Key pieces as you already might know for WCF REST services are – open up a “WebServiceHost”, add a “WebHttpBinding” and add a “WebHttpBehavior”.

ViewCount SOAP Service

Code Snippet
[ServiceContract] 
interface IViewCount
{
    [OperationContract]
    int GetViewCount(string PictureId);
 
    [OperationContract]
    void UpdateViewCount(string PictureId);
}

The service has two methods – one to get the view count of a picture and another to update it based on the Picture Id.

The only interesting thing about the service is that I am setting ServiceBehavior attribute with InstanceContextMode of single so that all concurrent accesses from multiple clients are processed sequentially to update the view count correctly.

Code Snippet
// Setting instance context to single so that multiple clients can update sequentially
[ServiceBehavior(InstanceContextMode = InstanceContextMode.Single)]
class ViewCountService : IViewCount

Again, service hosting is in the standard manner using BasicHttpBinding.

Code Snippet
// ***************   VIEW COUNT SOAP SERVICE   ***************   
string viewCountServiceAddress = "http://localhost/ViewCountService";
ServiceHost viewCountServiceHost = new ServiceHost(typeof(ViewCountService), new Uri(viewCountServiceAddress));
// Add service endpoints
viewCountServiceHost.AddServiceEndpoint(typeof(IViewCount), new BasicHttpBinding(), String.Empty);
// Enable metadata for the service
ServiceMetadataBehavior metadatBehavior = new ServiceMetadataBehavior();
metadatBehavior.HttpGetEnabled = true;
viewCountServiceHost.Description.Behaviors.Add(metadatBehavior);
 
viewCountServiceHost.Open();

Metro application

This is a C# Windows Metro style application.

When the application starts up I want to display the images available with the service. So I use an HttpClient to make a request to my REST service and retrieve the Picture Ids and then I use my REST service http url to get the picture associated with each id and assign them to an Image control:

Code Snippet
public async void DisplayImages()
{
    HttpClient client = new HttpClient();
    
    // Make an Http request to get the Picture Ids from the REST service
    HttpResponseMessage pictureIdsResponse = await client.GetAsync(pictureServiceAddress + "/GetPictureIds");
    if (pictureIdsResponse.IsSuccessStatusCode)
    {
        XDocument document = XDocument.Parse(pictureIdsResponse.Content.ReadAsStringAsync().Result);
        // Parse the picture Ids
        List<string> PictureIds = (from id in document.Root.Elements()
                                   select id.Value).ToList();
 
        // Assign each image control a picture from the service using an HTTP url.
        image1.Source = new BitmapImage(new Uri(String.Format("{0}/{1}={2}", pictureServiceAddress, "GetPicture?PictureId", PictureIds[0])));

Line 6 is where I am making a GET request to get the Picture Ids. The response is by default in Xml format so in Line 9, I am placing the response in an XDocument which I am then querying in line 11 to get the Picture Ids.

You can also make a call to the REST service from the browser directly with a Url http://localhost/PictureService/GetPictureIds, to get back the Xml response:

or the picture itself -

Now to view or update the view count – we need to access our WCF SOAP service. You need to generate a service reference to http://localhost/ViewCountService using the Add Service Reference (ASR) functionality. I mentioned the key differences in ASR generated code for Metro application in my previous post - http://blogs.msdn.com/b/piyushjo/archive/2011/09/22/wcf-in-win8-metro-styled-apps-absolutely-supported.aspx

Once the pictures are displayed, I want to display its view count when it is clicked or tapped. So I am using the Tapped event to do so:

Code Snippet
private void image_Tapped(object sender, Windows.UI.Xaml.Input.TappedEventArgs e)
{
    ShowImageDetails(((Windows.UI.Xaml.Controls.Image)sender).Tag.ToString()); 
}
 
async void ShowImageDetails(string PictureId)
{
    // Set the description image
    imageDetails.Source = new BitmapImage(new Uri(String.Format("{0}/{1}={2}", pictureServiceAddress, "GetPicture?PictureId", PictureId)));
    
    // Call the SOAP web service to get details - e.g. view count
    PhotoService.ViewCountClient proxy = new PhotoService.ViewCountClient();
    
    // Update the view count with the current view
    await proxy.UpdateViewCountAsync(PictureId);
    
    // And display the count
    ViewCount.Text = String.Format("View Count = {0}", await proxy.GetViewCountAsync(PictureId));
 
    await proxy.CloseAsync();
}

In Line 12, I am creating a proxy to my ViewCount SOAP service. In line 15, I am calling the UpdateViewCount method to go and update the view count for this Picture Id as someone tapped it to view it. And finally in line 18, I am getting the latest view count for this Picture Id by calling the GetViewCount method.

I have attached the service and the metro application solution. Both the REST and the SOAP services are hosted in the same console application and thus the same process. This service solution also contains a ConsoleClient to simulate a concurrently calling client which you can use to update the view count of pictures in the service which will then reflect in the Metro client UI when the metro client next calls the service.

The following is not needed anymore from BETA onwards and an exemption is automatically added while debugging from Visual Studio.

So now – you run the service and you run the metro client but you get -

System.Net.Http.HttpRequestException {"An error occurred while sending the request."} "Unable to connect to the remote server"

with the inner exception of {"A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond 127.0.0.1:80"}

If it would have been straightforward – I wouldn’t be writing this blog post, now would I? By default, metro client access to loopback address is blocked for network isolation. See more here - http://msdn.microsoft.com/en-us/library/windows/apps/hh452759(v=vs.85).aspx.

So what do you do – you need to run the CheckNetworkIsolation.exe tool described in the above MSDN link like the following:

CheckNetIsolation.exe LoopbackExempt –a –n=”PackageFamilyName”

This will add an exemption for our metro application to access the loopback address.

You may ask – how do I get this PackageMonikerName. For this - you need to open up the app manifest file:

Not only this, I also had to open up the firewall for the TCP port my service is listening by creating an Inbound rule. This is required on the BUILD preview Win8 release.

Once you have done the above two steps – adding an exemption for your metro app and creating a firewall rule, the metro client should be able to connect to the locally hosted web services.

Thank you!

What’s new in WCF 4.5 – generated client config cleaned

PiyushJo — Wed, 05 Oct 2011 08:09:00 GMT

One of our primary focuses this release was to simplify working with WCF. Configuration simplicity was right at the top since we know most of you find configuration hard and confusing.

We will talk about the configuration improvements in separate detailed posts but I wanted to highlight couple of small improvements in 4.5.

1) Reduced the mammoth client side generated config to only non-default values:

Well, if you are a WCF user, you would have definitely used the “Add Service Reference” (ASR) functionality or used svcutil.exe to point to a service WSDL to generate a service reference and associated configuration required to call the service. I bet, you would have also noticed the huge configuration file where we used to dump all the binding properties and trust me, WCF has quite a few of these

To remind you of the ugly sight which present you – here is what you get today with Visual Studio 2010 when you generate a service reference for a simple WCF service with a single endpoint and basicHttpBinding:

In Visual Studio 2011, we have fixed this and when you generate a service reference – you will get much neater and cleaner config file which we hope, you will find much simpler:

Notice that the entire binding section has been trimmed down. We will only generate non-default values here so say for e.g. I changed the message encoding on the service to “Mtom” and I regenerate the service reference on the client – I will get the following. Notice that we have generated only the non-default value of messageEncoding here.

While on the topic of discovering little gems around configuration – here is another one.

2) Made the WCF config editor easily discoverable

This was one of my pet peeves. I really like the Configuration editor tool even though it is not as powerful as it could be. Even in its current form, it allows me to make configuration changes easily without requiring me to remember every config property WCF has to offer by its name and location. We have shipped this tool in the previous releases and yet, very few folks actually know about it let alone use it. And one of the key reasons was that we used to hide it somewhere in the tools menu where very few folks poke around. Once you have opened the configuration file via this tool, a right click context menu item belatedly used to appear for the configuration file to allow easy access thereafter. But – good luck finding it the first time!

Now it is available as a right click gesture right there on the config file from the time you open up a new WCF project as “WCF Service application” or “WCF Service library” templates. So hopefully, you can find it and use it more often!

Thank you!

What’s new in WCF 4.5 – Flat WSDL support

PiyushJo — Wed, 05 Oct 2011 06:44:00 GMT

As I promised – I’ll be blogging about the new features introduced in WCF 4.5 here. Before getting into big features, lets start with a few small gems. The first one is the support for Flat WSDL!

Interoperability with non-.NET stacks has always been important to us at WCF and there have been instances where some such clients haven’t been able to consume the WSDL generated from a WCF service. WCF, by default generates a WSDL in modular format. This means that the WSDL document specifies its dependencies via xsd:import attributes. Schema types in particular are always generated as separate XSD files. If you look at a typical WSDL file generated by a WCF service – here is what you will notice near the top section.

Modular WSDL while having its advantages, is not understood by some of the non-.Net stacks leading to interoperability issues. Customers implemented tedious workarounds to make this all work. Not anymore! Enter the support for Flat WSDL in WCF. This means, as you would have guessed by its name, there is a single WSDL document and no external references to schema types or anything else. I am attaching a 4.0 generated modular WSDL and the corresponding flat WSDL with the blog post so that you can compare and see the difference yourself.

What this means:

Improved interoperability support for all the third party WSDL processing stacks like PHP, Flex, Powerbuilder or Infopath which have been unable in the past to consume a WCF modular WSDL without running into issues.
No more problems when the xsd:import referred to some internal location because say the WCF service was behind a firewall producing a WSDL with schemaLocations pointing to unresolvable URIs and thereby requiring manual correction in the entire downloaded WSDL and all the referenced files as well. I have done that and it as terrible!
No more dealing with a whole boatload of files when downloading the metadata from a complex service now that the entire metadata is contained within a single WSDL file now.

So, you ask – what do I have to do to take advantage of this fantastic feature – well the answer, as Seinfeld would put it - is “Nothing”. You just enable metadata how you have always done by enabling the serviceMetadata attribute for a 4.5 service and you will see the following “additional” link on your now familiar metadata description page -

You can continue to import the WSDL as you have always done if you do not need the flat WSDL support. However if you do need WSDL in the flat format – you get it from the second link – notice the ?singleWsdl at the end instead of ?wsdl.

Thanks.

Azure Service Bus–working with the appfabriclabs account

PiyushJo — Tue, 27 Sep 2011 08:26:00 GMT

So I have been playing with Azure Service Bus lately. I have created an Azure AppFabric Labs account for myself and this allows me to easily get started with and try Azure AppFabric services like Service Bus, Access Control Service and Cache for my sample applications.

When I started with my first basic Service Bus sample which simply creates a WCF service and registers itself to the Service Bus to enable the queue to listen for messages, I ran into couple of interesting issues which took a bit of online search time to figure out. I am describing the solution here in case anyone else finds themselves in the same shoes as mine.

First - I got the following error when I started my simple WCF service host.

I figured that this is because my service bus namespace is situated in labs environment. So I modified the code while creating the service address to replace the domain:

// Create the service uri based on service namespace Uri serviceAddress = ServiceBusEnvironment.CreateServiceUri ("sb", serviceNamespace, "MyEchoService");serviceAddress = new Uri(serviceAddress.ToString().Replace ("windows.net", "appfabriclabs.com"));

However, even after my above fix, the problem didn't go away and I ran into another error message:

uri provided <myNamespace>.servicebus.appfabriclabs.com does not match service bus domain: servicebus.windows.net

It turns out that the fix to redirect from servicebus.windows.net to servicebus.appfabriclabs.com environment is simple once you know it and there is no change in code required, not even correcting the service address bit I did above. All you need to do is to create an xml file named ServiceBus.xml with the following content in the …\Microsoft.Net\Framework(64)\<version>\Config directory:

<?xml version="1.0" encoding="utf-8"?> 
<configuration>
   <Microsoft.ServiceBus>
     <relayHostName>servicebus.appfabriclabs.com</relayHostName>
     <stsHostName>accesscontrol.appfabriclabs.com</stsHostName>
    <acmHostName>accesscontrol.appfabriclabs.com</acmHostName>
   </Microsoft.ServiceBus>
</configuration>

More on this here - http://abhishekrlal.wordpress.com/2011/03/22/clientsdkconfig/.

There is a catch though – you should also check the “Platform target” setting of your application before deciding where to put this ServiceBus.config. If your application is set to AnyCPU, which is the default, then on a 64 bit machine you will put the above ServiceBus.config in the Framework64\…\Config directory otherwise in the Framework\…\Config directory. However if the Platform target is explicitly set, then you will need to place the file depending on the setting here – e.g. if Platform target is set to x86, then even on a 64 bit machine – above config file will go in the Framework\…\Config (and not Framework64\…\Config) directory.

WCF in Windows 8 Metro styled apps? Absolutely supported

PiyushJo — Thu, 22 Sep 2011 05:56:00 GMT

[Updated for Win8/Dev11 Beta]

Hi all,
With Windows 8 metro styled applications getting a great buzz - I thought this was a perfect time to introduce the WCF support for Metro applications.

We provide support for WCF client inside a Metro application with a subset of features compared to classic desktop applications. See here - http://blogs.msdn.com/b/piyushjo/archive/2011/10/19/wcf-for-metro-apps-supported-functionality.aspx for the supported feature list. This enables you to consume all those awesome web services out there, in your metro app very easily and as we will see – very similar to what you are already used to.

We will start with a simple Metro application in C# and consume an ASMX web service (one of the first weather services I found in my search results). The application in its current form will be a simple weather reporting client taking in a US zip code and displaying the weather by calling an external web service hosted here - http://wsf.cdyne.com/WeatherWS/Weather.asmx. The point of the demo is to clarify the client experience for Win8 Metro app.
In future blog posts, we will extend the application to include more of supported WCF features and will consume WCF services which is likely going to be the norm.

1. Open Visual Studio 11 and create a new Windows Metro style Blank application.

2. In your application - right click on References and add the service reference to http://wsf.cdyne.com/WeatherWS/Weather.asmx service just as you do for classic desktop apps. This will generate a service reference to this weather service.

3. So far nothing out of the ordinary - everything is exactly the same as what we are used to while adding a service reference to a web service.

The fun starts now:
a) First note that there is no configuration file generated. Metro apps do not support the traditional xml styled application so we have modified our Add Service Reference (ASR) experience from within a metro app to generate code based configuration.
Where will you find this generated code? Go to the Reference.cs file generated under the service reference folder. You will have to click "Show All Files" in Solution explorer.
You will see code like the following for the generated binding and endpoint address:

Code Snippet
 private static System.ServiceModel.Channels.Binding GetBindingForEndpoint(EndpointConfiguration endpointConfiguration) {
    if ((endpointConfiguration == EndpointConfiguration.WeatherSoap)) {
        System.ServiceModel.BasicHttpBinding result = new System.ServiceModel.BasicHttpBinding();
        result.MaxBufferSize = int.MaxValue;
        result.ReaderQuotas = System.Xml.XmlDictionaryReaderQuotas.Max;
        result.MaxReceivedMessageSize = int.MaxValue;
        result.AllowCookies = true;
        return result;
    }
    throw new System.InvalidOperationException(string.Format("Could not find endpoint with name \'{0}\'.", endpointConfiguration));
}
private static System.ServiceModel.EndpointAddress GetEndpointAddress(EndpointConfiguration endpointConfiguration) {
    if ((endpointConfiguration == EndpointConfiguration.WeatherSoap)) {
        return new System.ServiceModel.EndpointAddress("http://wsf.cdyne.com/WeatherWS/Weather.asmx");
    }
    throw new System.InvalidOperationException(string.Format("Could not find endpoint with name \'{0}\'.", endpointConfiguration));
}
 

Now this also means that if you need to change any binding properties on the client side - you need to do this in code. You can use the newly generated partial method ‘ConfigureEndpoint’ to implement any changes outside the generated proxy class so that you can update the generated proxy (including Reference.cs) without any fear of your changes being overwritten.

Code Snippet
 public partial class WeatherSoapClient : System.ServiceModel.ClientBase<MetroTestApp.WeatherService.WeatherSoap>, MetroTestApp.WeatherService.WeatherSoap {
        
        /// <summary>
        /// Implement this partial method to configure the service endpoint.
        /// </summary>
        /// <param name="serviceEndpoint">The endpoint to configure</param>
        /// <param name="clientCredentials">The client credentials</param>
        static partial void ConfigureEndpoint(System.ServiceModel.Description.ServiceEndpoint serviceEndpoint, System.ServiceModel.Description.ClientCredentials clientCredentials);
 

b) Next - you will also notice a difference in the style of operations generated for the service.
Note that you only have task based async patterned methods generated. This ensures that there are no blocking calls from the metro styled UI apps, even unknowingly.
If you will generate a similar service reference from a classic desktop app in Dev11 - you will see both synchronous and task based async methods. Task based async pattern is the recommended pattern for doing async programming going forward therefore in Add Service Reference - Advanced dialog, we select it for you by default:

4) That’s it. Thereafter you can call the service asyn using the following Task based async model:

Code Snippet
 private async void GoButton_Click(object sender, RoutedEventArgs e)
{
    WeatherSoapClient proxy = new WeatherSoapClient();
    WeatherReturn result = await proxy.GetCityWeatherByZIPAsync(inputZipCode.Text);
    if (result.Success)
    {
        resultCityState.Text = String.Format("{0}, {1}", result.City, result.State);
        resultDetails.Text = String.Format
            ("\nConditions - {0} \nTemperature - {1}F \nRelative Humidity - {2} \nWind - {3} \nPressure - {4}",
            result.Description, result.Temperature, result.RelativeHumidity, result.Wind, result.Pressure);
    }
    else
    {
        resultCityState.Text = "City not found";
    }
}
 

Note that the method is marked async and we are making the service call with the await keyword.

5) You don’t have to provide any additional capability and the default capability Internet (Client) is sufficient.

So that was pretty much it! For you - while developing metro apps - you just need to be aware that:

1) You need to make all configuration in code.
2) You need to make all service calls async using the task based pattern.

Attached is a sample app which contains two projects - one is a metro styled app and another a regular console app making the same service call. You can compare the generated service references to get more insight.

Sample code attached.

MetroSimpleSample

Thanks!

Visual Studio 2011 and .Net framework 4.5 announced at BUILD conference

PiyushJo — Tue, 20 Sep 2011 06:53:00 GMT

Hi everyone,

As you all know that we announced Visual Studio 2011 and the next framework version v4.5 at BUILD conference last week.

Please note that we are using the combined forum here - http://forums.asp.net/1239.aspx/1?ASP+NET+4+5+Developer+Preview+and+Visual+Studio+11+Developer+Preview for answering all WCF v4.5 preview related questions. Please post all such questions there to get quick set of eyes.

WCF v4.5 feature list:

Here is a quick list of features/enhancements we are bringing in WCF v4.5, your feedback is welcome. I will be blogging about these in detail in the next few days.

Scalable modern communication stack

- Scalable, bi-directional communication over HTTP using WebSockets

- Interoperable public UDP multi-cast channel

- TCP support for high-density scenarios (partial trust)

- Support for Tasks and the new C# Async language features throughout WCF programming model

- Improved streaming support

- Compression support (gzip/deflate) for binary encoding

Continued commitment to simplicity

- Further config simplification, config intellisense, making WCF throttles/quotas smarter & work for you by default!

- Support for multiple authentication modes on a single WCF endpoint

- Better manageability via rich ETW & e2e tracing

- XSD-first type authoring experience

- Support for Internationalized Domain Name (IDN) WCF services.

Win8

Support for WCF client in Win8 immersive applications with basicHttp/netTcp/WebSocket* bindings.

[*WebSocket support for Win8 WCF Immersive apps is not present in the current preview release but we are working to add it in the final 4.5 release]

Interesting BUILD talks

1) Building Web APIs in Windows Azure with WCF to reach any device - http://channel9.msdn.com/Events/BUILD/BUILD2011/SAC-798T , Glenn Block

2) Building real-time web apps with WebSockets using IIS, ASP.NET and WCF http://channel9.msdn.com/Events/BUILD/BUILD2011/SAC-807T , Paul Batum, Stefan Schackow

3) Building data-driven HTML5 apps with WCF RIA Services http://channel9.msdn.com/Events/BUILD/BUILD2011/TOOL-800T , Dinesh Kulkarni

4) Building real-time web apps with HTML5 WebSockets http://channel9.msdn.com/Events/BUILD/BUILD2011/PLAT-373C , Ravi Rao

5) What's new in .NET Framework 4.5 http://channel9.msdn.com/Events/BUILD/BUILD2011/TOOL-834T , Joshua Goodman

6) Building and running HPC apps in Windows Azure http://channel9.msdn.com/Events/BUILD/BUILD2011/SAC-452T , Greg Burgess.

Thanks and please do tell us which features excite you the most!