Ido Flatow's Blog

Veni Vidi Scripsi

Hi, my name is Ido Flatow, and in this session we will talk about…

Ido Flatow — Thu, 22 Mar 2012 22:23:00 GMT

In the next couple of months, I’m going to say that phrase many times.

My speaking engagements last year at VSLive in Redmond and Orlando, and in the North-American MCT Summit in San-Francisco marked my first steps into the world of becoming an international speaker. Until that time, most of my speaker experience came from speaking back home in Israel in courses and conferences, and here and there teaching a course abroad in Sela’s branches in the world. Speaking in a conference is somewhat similar to a course, only 10x times the size of the audience, and more pressure since you only have one hour to make a good impression instead of an entire week.

And now it’s time for the 2012 conferences. These next couple of months are going to be quite hectic, with conferences worldwide, and me skipping from one continent to the other. So here is my appearance list, just in case you are one of my groupies and wish to attend each of my sessions .

March 25-29 – Sela Developer Practice (SDP). Sela, Israel.

In our annual conference I will deliver two workshops:

1. Advanced WCF – In this 1-day workshop I will show monitoring techniques for WCF, discuss about WCF performance, demonstrate various WCF security concepts, and show some useful tips for accessing WCF from client applications. In addition, I will demonstrate how to extend WCF by creating custom behaviors.

2. Debugging the web with Fiddler – In this 1-day workshop I will show you how to use Fiddler from bottom to top: how to inspect sessions, filter requests and responses, check statistics and timeline, use the composer and auto-responder, and how to create your own inspector and custom handler for Fiddler.

April 17-20 - Great Indian Developer Summit (GIDS). Bangalore, India.

This will be my first appearance in GIDS, and my first time to India, so I’m twice as happy to speak at the conference. In GIDS I will have four sessions:

1. What’s new in WCF 4 – simplified configuration, better IIS hosting, routing and discovery services and more. Many groups are still in the process of migrating from previous versions of .NET (1.1, 2, 3.5) to .NET 4, so if you are migrating to WCF 4, or already using it and want to learn more about it, this session is for you.

2. What’s new in WCF 4.5 – UDP transport, WebSocket support, configuration Intellisense, streaming improvements, etc.. If you want to learn about the new features which will be available late this year in .NET 4.5 you should definitely come (or at the least start by reading my posts about it).

3. ASP.NET MVC Razor And jQuery: The New Face Of ASP.NET – so many new frameworks and concept that will make every web developer’s head spin. Unfortunately this is only a 1-hour session, so we won’t be able to touch ground on all the technologies, but at least we will have enough time to talk about MVC, jQuery, and Razor, as the new way for building web applications.

4. Introducing The Windows Azure HPC Scheduler – doing HPC using Windows HPC Server? with the new release of the Windows Azure HPC Scheduler, you can migrate your entire solution to the cloud without using any local cluster, and use the Windows Azure cloud elasticity to increase/reduce resources as needed.

May 14-17 – Visual Studio Live (VSLive). New York, USA.

This will be my third appearance at VSLive, but I’m as excited as ever, as I will be presenting three sessions, back-to-back, all of them about WCF:

1. What's new in WCF 4 – as mentioned before, a very useful session if you are currently migrating to .NET 4.

2. What’s new in WCF 4.5 – just imagine being in a conference room and listening to 2 hours of new WCF features (4 & 4.5). If I were you, I would just wait to get back to the office to try it out.

3. Monitoring and troubleshooting WCF services – trace files, message logs, ETW, WMI, performance counters, AppFabric monitoring … Come and see all the ways for monitoring your WCF services. In addition we will discuss various aspects of instance modes and concurrency in WCF, and go over many of the settings in WCF that can affect the performance of your services.

June 6-8 – Norwegian Developers Conference (NDC). Oslo, Norway.

First time to NDC, but this time I will not fly alone. My colleague, Yaniv Rodenski, is also a speaker at NDC where he will have a session on Hadoop on Windows Azure. As for me, I will only have one session this time, so I’ll have more time to visit Oslo:

Debugging the Web with Fiddler – learn to use Fiddler, the famous Web debugger, to inspect requests and response, catch message as they pass and alter them, create responses without ever reaching the server, and write your own extensions to Fiddler. I recommend you install Fiddler on your laptop prior to the session so you can try it out during my talk.

August 6-10 – Visual Studio Live (VSLive). Redmond, WA, USA.

Back again to the Microsoft campus on Redmond, this will be my fourth VSLive conference, and second time as a speaker in the Redmond event. Luckily for me, I will not have to endure the 16 hours of flight (not including layovers) alone, since I will be accompanied by Gil Fink, another one of my colleagues, who is also speaking at VSLive on HTML5 and Entity Framework. As for me, my sessions are:

1. Building secured, scalable, low-latency web applications with the Windows Azure Platform – in the past years, whenever you saw a session about Web apps in Windows Azure, you always got a lot of slides, and a bit of demo code. Well no more! this is a 1-hour code only session where I will show how to create a Web application for Windows Azure that utilizes everything Azure has to offer – compute, storage, CDN, ACS, AppFabric Cache, SQL Azure, Full IIS, WCF worker roles and more.

2. Embracing HTTP with ASP.NET Web APIs – although I’ve always been the “WCF guy”, I’m in the business of Web technologies, and you can’t build proper Web apps without harnessing the full power of the HTTP protocol. In this session I will show you what the new ASP.NET Web API is all about, and how you can use it to build HTTP services.

That’s the agenda for now, and I guess that there will be more updates in the next couple of weeks. My calendar for September-December is still opened, so if you want to book me for a conference, let me know.

I will also tweet with live updates from the conferences, so don’t forget to follow me @IdoFlatow

What’s new in WCF 4.5? WebSocket support (Part 2 of 2)

Ido Flatow — Tue, 06 Mar 2012 13:57:14 GMT

It’s time for post No. 12 in the WCF 4.5 series. Part 1 of 2 was about WebSocket support with SOAP-based messages. Part 2 is about WebSocket support with plain text messages that enables the interaction between web browsers and WCF.

1. What’s new in WCF 4.5? let’s start with WCF configuration

2. What’s new in WCF 4.5? a single WSDL file

3. What’s new in WCF 4.5? Configuration tooltips and intellisense in config files

4. What’s new in WCF 4.5? Configuration validations

5. What’s new in WCF 4.5? Multiple authentication support on a single endpoint in IIS

6. What’s new in WCF 4.5? Automatic HTTPS endpoint for IIS

7. What’s new in WCF 4.5? BasicHttpsBinding

8. What’s new in WCF 4.5? Changed default for ASP.NET compatibility mode

9. What’s new in WCF 4.5? Improved streaming in IIS hosting

10. What’s new in WCF 4.5? UDP transport support

11. What’s new in WCF 4.5? WebSocket support (Part 1 of 2)

If you haven’t read part 1, please go over it first so you can get the gist about WebSockets, NetHttpBinding, and how it is used in WCF.

In part 1 I demonstrated how to create both binary encoded SOAP bindings and text encoded SOAP bindings with WebSockets. Problem is that in JavaScript it can get difficult to create and parse SOAP messages - this is why we tend to use XML/JSON based bindings (such as WebHttpBinding) instead of SOAP-based bindings (BasicHttpBinding/WsHttpBinding) when calling WCF services from JavaScript.

Creating a duplex service with WebSockets, NetHttpBinding, and plain text messages, is just like creating any other WCF service:

Define the contract and callback contract
Implement the service
Configure the host
Consume the service from a client app

First we will create our contract. Since we need to receive and send messages, we will create a duplex contract, each contract with a single method which we will mark with action=”*”:

Contracts
 [ServiceContract]
public interface IWebSocketEchoCallback
{        
    [OperationContract(IsOneWay = true, Action = "*")]        
    void Send(Message message);
}
 
[ServiceContract(CallbackContract = typeof(IWebSocketEchoCallback))]
public interface IWebSocketEcho
{
    [OperationContract(IsOneWay = true, Action = "*")]
    void Receive(Message message);
}
 

The echo service itself is a simple implementation that receives the message and sends it back to the client:

EchoService
 public class EchoService : IWebSocketEcho
    {
        IWebSocketEchoCallback _callback = null;
 
        public EchoService()
        {
            _callback =
                OperationContext.Current.GetCallbackChannel<IWebSocketEchoCallback>();
        }
        public void Receive(Message message)
        {
            if (message == null)
            {
                throw new ArgumentNullException("message");
            }
 
            WebSocketMessageProperty property = 
                (WebSocketMessageProperty)message.Properties["WebSocketMessageProperty"];
            WebSocketContext context = property.WebSocketContext;
            var queryParameters = HttpUtility.ParseQueryString(context.RequestUri.Query);
            string content = string.Empty;
 
            if (!message.IsEmpty)
            {
                byte[] body = message.GetBody<byte[]>();
                content = Encoding.UTF8.GetString(body);                
            }
 
            // Do something with the content/queryParams
            // ...
            
            string str = null;
            if (string.IsNullOrEmpty(content)) // Connection open message
            {
                str = "Opening connection from user " + 
                    queryParameters["Name"].ToString();                
            }
            else // Message received from client
            {
                str = "Received message: " + content;                
            }
 
            _callback.Send(CreateMessage(str));            
        }
 
        private Message CreateMessage(string content)
        {
            Message message = ByteStreamMessage.CreateMessage(
                new ArraySegment<byte>(
                    Encoding.UTF8.GetBytes(content)));
            message.Properties["WebSocketMessageProperty"] =
                new WebSocketMessageProperty
                { MessageType = WebSocketMessageType.Text };
                        
            return message;
        }
    }
 

The Receive method handles two types of calls:

1. The first “connection upgrade” message – when the client first connects to the service and tries to upgrade the connection from HTTP to WebSocket. In this call the request is sent using HTTP GET, and therefore there is no body, but we can access the URL’s query string.

2. The second message and on are the messages being sent by the client over the WebSocket transport – these messages contain a message body, with no special query string.

Line 5-9 shows how to create a standard duplex service by storing the callback channel in a local variable. The callback channel will be used later on in the code in order to send messages back to the client. The service uses the default instancing mode which is PerSession, so a new instance will be created for each client, and the local variable will point to a different callback channel in each service instance.

Lines 17-27 demonstrates the technique of parsing the message – either by checking its query string or by reading the byte array from the message and transforming it to a string.

Lines 32-43 checks which type of message is being handled, the first connection request, or a consequent message from the client. In each case the service responds by echoing the message back to the client.

Line 46-56 demonstrates how to create a Message object with a simple string content when using the byte stream encoding.

Note: to use the ByteStreamMessage type, add a reference to the System.ServiceModel.Channels assembly.

Note: WebSocket messages can be either text or binary, so if you are planning on using binary messages you will need to change the code to work with byte arrays instead of strings.

Now that we have the contracts and the service, we need to define our host and endpoint. In this example I will use IIS as the host and I will use the routing mechanism of ASP.NET to create a service URL address that doesn’t contain the annoying “.svc” extension. The following global.asax code shows how to do that:

Global.Asax
 public class Global : System.Web.HttpApplication
{
    protected void Application_Start(object sender, EventArgs e)
    {
        RouteTable.Routes.Add(new ServiceRoute("echo",
            new ServiceHostFactory(),
            typeof(EchoService)));
    }
}
 

And now for the endpoint configuration. Since NetHttpBinding uses SOAP messages, and there is no “WebSocketHttpBinding” for passing plain byte streams, we need to create a custom binding that will allow us to receive messages over WebSocket where the message can either be a text message or a binary message (the WebSocket API supports both types).

The standard encodings of WCF - text, binary, and MTOM, will not enable us to receive non-SOAP byte streams, that is why we need to use a new encoding which was introduced in WCF 4 – the ByteStreamMessageEncoding.

The following endpoint and binding configuration will allow us to open a WebSocket listener that receives simple byte streams:

Service Configuration
  <system.serviceModel>
    <serviceHostingEnvironment aspNetCompatibilityEnabled="true" 
                               multipleSiteBindingsEnabled="true" />
    <services>
      <service name="UsingWebSockets.EchoService">
        <endpoint address="" 
                  binding="customBinding" 
                  bindingConfiguration="webSocket"
                  contract="UsingWebSockets.IWebSocketEcho" />
      </service>
    </services>
    <bindings>
      <customBinding>
        <binding name="webSocket">          
          <byteStreamMessageEncoding/>            
          <httpTransport>            
            <webSocketSettings transportUsage="Always" 
                               createNotificationOnConnection="true"/>
          </httpTransport>
        </binding>
      </customBinding>
    </bindings>
  </system.serviceModel>
 

The important part in the configuration is lines 13-21:

1. We set the transportUsage to Always to force the usage of WebSocket rather than HTTP.

2. We set the createNotificationOnConnection to true to allow our Receive method to be invoked for the connection request message (the first GET request which is sent to the service).

3. We use the byteStreamMessageEncoding which allows the service to receive simple byte streams as input instead of complex SOAP structures.

To test our code we can add an HTML page to our project. The following code is based on the StockTicker demo from the HTML5 Labs website:

Echo Client
 <!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
    <title>Echo Demo</title>
    <script src="Scripts/jquery-1.4.1.js" type="text/javascript"></script>
    <script>
 
        $(document).ready(function () {
            if (!window.WebSocket && window.MozWebSocket) {
                window.WebSocket = window.MozWebSocket;
            }
 
            $('#echoForm').submit(function (event) {
                $('#echoForm')
                    .add('#echoForm > *')
                    .attr('disabled', 'disabled');
 
                var uri = 'ws://' + window.location.hostname +
                    window.location.pathname.replace('EchoDemo.html', 'echo') +
                    '?Name=' + $("#name").val();
                connect(uri);
                event.preventDefault();
            });
 
        });
 
        function connect(uri) {
            $('#messages').prepend('<div>Connecting...</div>');
 
            var websocket = new WebSocket(uri);
            
            websocket.onopen = function () {
                window.focus();
                $('#echoForm').hide();
                $('#outputArea').show();
                window.setInterval(function()
                {
                   websocket.send("the time is " + new Date());
                }, 1000);                
                $('#messages').html(
                    '<div>Connected. Waiting for messages...</div>');
            };
 
            websocket.onclose = function () {
                if (document.readyState == "complete") {
                    var warn = $('<div>').html(
                        'Connection lost. Refresh the page to start again.').
                        css('color', 'red');
                    $('#messages').append(warn);
                }
            };
 
            websocket.onmessage = function (event) {
                $("#messages").append(event.data + "<br>");
            };
        };
 
</script>
</head>
<body>
    <form id="echoForm" action="">
    <input type="text" id="name" placeholder="type your name" />
    </form>
            <div id="outputArea" style="display: none">
        <div id="messages" style="height: 80%; overflow: hidden">
        </div>
    </div>
</body>
</html>
 

Most of the above code is jQuery stuff to handle the incoming message, so let’s point out the important parts:

Lines 18-20 – In these lines we create the URI of the service. Note the use of the ws:// scheme – this is the scheme of WebSocket, but it works just fine even when our service base address is set to HTTP.

Lines 27-56 – the connect function basically does all the rest. The WebSocket functions are based on the WebSocket API

Line 30 – create the WebSocket object
Lines 32-42 – open the connection
Lines 36-49 – run a function every 1 second that sends the current time to the service
Lines 44-51 – handle the WebSocket channel closing
Lines 53-55 – handle a received message (a message sent from the service to the client)

Running the client will show the following output:

To conclude, in order to create a service that can receive and send message to browsers using WebSockets we need to do the following:

Create the duplex contract which contains a simple Receive and Send methods (or any other names you like).
Implement the contract in a service like you’ll implement any other duplex service. The only thing you need to take care of is how to read and write the message.
Create an endpoint which uses a custom binding which supports WebSockets and simple byte-stream encoding.

Although the above works quite well, there is another way to create this type of service – by creating a service class that inherits from the Microsoft.WebSockets.WebSocketService type. The Microsoft.WebSockets package, available from NuGet, enables the creation of WebSocket-based services. Once inheriting your service from WebSocketService, you can override methods such as OnMessage, OnOpen, OnClose, and OnError. Working with these methods is quite easy, as demonstrated in the following code:

EchoService2
 public class EchoService2 : 
     Microsoft.ServiceModel.WebSockets.WebSocketService
 {
     public override void OnMessage(string message)
     {
         string str = "Received message: " + message;
         Send(str);
     }
     
     public override void OnOpen()
     {
         var queryParameters = this.QueryParameters;
         string str = "Opening connection from user " +
             queryParameters["Name"].ToString();
 
          Send(str);                        
     }
 
     protected override void OnClose()
     {
         base.OnClose();            
     }
 
     protected override void OnError()
     {
         base.OnError();            
     }
 }
 

As you can see, in this case you don’t have to work directly with byte arrays. In order to host this service you also don’t need to define a special endpoint configuration, as this package includes a WebSocketHost class that automatically creates and configures a WebSocket endpoint. To create a WebSocketHost and provide it to IIS, we need to create a class that inherits from ServiceHostFactory, as demonstrated in the following code :

WebSocketServiceHostFactory
 public class WebSocketServiceHostFactory : ServiceHostFactory
  {
      protected override ServiceHost CreateServiceHost(Type serviceType, 
          Uri[] baseAddresses)
      {
          var host = new WebSocketHost(serviceType, baseAddresses);
          
          host.AddWebSocketEndpoint();
 
          return host;
      }        
  }    
 

Note: the ServiceHostFactory is declared in the System.ServiceModel.Activation assembly, so don’t forget to add a reference to it.

Once we have the new factory, we can register it with the routing mechanism (lines 5-7):

Global.Asax
 public class Global : System.Web.HttpApplication
  {
      protected void Application_Start(object sender, EventArgs e)
      {
          RouteTable.Routes.Add(new ServiceRoute("echo2",
              new WebSocketServiceHostFactory(),
              typeof(EchoService2)));
 
          RouteTable.Routes.Add(new ServiceRoute("echo",
              new ServiceHostFactory(),
              typeof(EchoService)));
      }
  }
 

All is left is to change the client HTML code in line 19 to call the ‘echo2’ service instead of ‘echo’.

You can see more examples on how to use this package in Paul Batum’s blog post, and in his //BUILD session.

So as you can see, it is quite easy to create a WCF service that can receive messages from a browser and push messages to a browser by using WebSockets. Farewell long polling, I hope we never meet again

You can download the above code (both versions) from my SkyDrive. The source code also includes a sample self-hosted WebSocket service and an HTML page that uses it instead of the IIS-hosted service.

WCF or ASP.NET Web APIs? My two cents on the subject

Ido Flatow — Mon, 05 Mar 2012 11:39:12 GMT

A couple of weeks ago (around Feb. 16) the WCF WebAPIs - a framework for building RESTful/Hypermedia/HTTP services, which was in development over the past 1.5 years as a side-project on CodePlex, has been formally integrated into ASP.NET and its name changed to the ASP.NET Web API.

These past two weeks, there has been a lot of questions among WCF developers: What does it mean that the Web APIs are no longer a part of WCF – is WCF dead? Has SOAP gone bankrupted? is HTTP the new way to go for interoperability?

To get a better understanding of what happened and what is the way to go, we need to answer a couple of questions:

1. What is the purpose of the WebAPIs?

2. Why do we need ~~REST~~ HTTP services? What’s wrong with SOAP-over-HTTP?

3. Why did the WebAPIs move from WCF to ASP.NET MVC?

4. Is there still a use for WCF? When should I choose Web APIs over WCF?

What is the purpose of the WebAPIs?

When WCF was conceived back in its Indigo and .NET 3 days, the main goal was to support SOAP + WS-* over a wide variety of transports. However, over time it became clear that although SOAP is wide spread and supported on many platforms, it is not the only way to go when creating services. There is also a need to also support non-SOAP services, especially over HTTP, where you can harness the power of the HTTP protocol to create HTTP services: services that are activated by simple GET requests, or by passing plain XML over POST, and respond with non-SOAP content such as plain XML, a JSON string, or any other content that can be used by the consumer. Support for non-SOAP services was very much needed in WCF back then, mostly because some clients, such as web browsers, were not that suitable to handle SOAP messages (plenty of XML parsing and DOM manipulation).

So in WCF 3.5 we got the WebHttpBinding – a new binding that helped us create this kind of non-SOAP service over HTTP, better known as a RESTful service.

The WebHttpBinding was not enough, and after WCF 3.5 was released, a new set of tools was created – the WCF REST Starter Kit. The REST starter kit was an attempt to enrich the support of WCF 3.5 for HTTP services – add better client-side support for .NET apps, extend the server side support for other content types, enable response and request caching, inspection of messages and so forth. Unfortunately, this great toolkit was never officially released and ended its product cycle as “Preview 2”, although it’s still being used today in some of Microsoft’s products that are built with .NET 3.5.

Although not released, some of the service-side features of the REST starter kit were integrated into WCF 4 – we didn’t get any of the client-side libraries, but we did get most of the service-side features (excluding the new inspectors). Some were well-integrated into WCF while others required the use of ASP.NET (by turning on the ASP.NET compatibility mode).

So with WCF 4 we had some support for “Web” HTTP services, but it wasn’t that perfect – to get some of the features you needed IIS hosting and ASP.NET, not all types of requests were supported easily (ever tried posting HTML form data to a WCF HTTP service?), the overuse of CLR attributes to define the POST/GET/PUT/DELETE was tedious, not to mention the configuration required to create this type of services with all of the endpoint behavior. And even after all of that we didn’t actually get full control over the HTTP messages.

That was the main goal of the Web APIs, known back then as the WCF Web APIs: to stop looking at HTTP through the eyes of WCF - as just a transport protocol to pass requests. Rather, it allows us to look at it as the real application-level protocol it is – a rich, interoperable, resource-oriented protocol. The purpose of the Web APIs was to properly use URIs, HTTP headers, and body to create HTTP services for the web, and for everyone else that wished to embrace HTTP as its protocol and lifelong friend.

Why do we need ~~REST~~ HTTP services? What’s wrong with SOAP-over-HTTP?

The world of SOAP and the world of HTTP services are very different. SOAP allows us to place all the knowledge required by our service in the message itself, disregarding its transport protocol, whether it is TCP, HTTP, UDP, PGM, Named Pipes… But unlike TCP, UDP and the other level 4-5 protocols, HTTP is an application-level protocol, and as such it offers a wide variety of features:

It supports verbs that define the action - query information using GET, place new information and update existing using POST or PUT, remove information using DELETE etc.
It contains message headers that are very meaningful and descriptive - headers that suggest the content type of the message’s body, headers that explain how to cache information, how to secure it etc.
It contains a body that can be used for any type of content, not just XML content as SOAP enforces (and if you want something else – encode it to base64 strings and place it in the SOAP’s XML content). The body of HTTP messages can be anything you want – HTML, plain XML, JSON, binary files (images, videos, documents…) …
It uses URIs for identifying both information paths (resources) and actions – the URI templates initiative is catching on and is rapidly becoming the standard way of representing requests for resources and hypermedia URIs.

The use of HTTP has evolved over the years. Application-level protocol architectural styles such as ~~REST~~ Hypermedia APIs have emerged on top of HTTP. These, in turn, harness the power of HTTP to create resource-oriented services, and better define the stateless interaction between clients and services.

The Web APIs therefore were intended to allow all of these approaches – you can use it to create HTTP services that only use the standard HTTP concepts (URIs and verbs), and to to create services that use more advanced HTTP features – request/response headers, hypermedia concepts etc.

So HTTP is a lot more than a transport protocol. It is an application-level protocol, and the fact is that although many platforms know how to use SOAP, many more platforms know how to use HTTP! among the HTTP supporting platforms which do not support SOAP that well are the browsers – probably the most important platforms for web developers (and users). And if you don’t believe me that REST and hypermedia are useful, maybe Martin Fowler can convince you better than me.

This, of course, does not mean that SOAP is redundant – SOAP is still useful for building messages when you don’t have an alternative application-level protocol at your disposal, or when you want to use SOAP across the board while considering HTTP as no more than another way to pass messages (for example, use HTTP because it can cross firewalls more easily than TCP).

Why did the WebAPIs move from WCF to ASP.NET MVC?

Back to the story of WCF and the WCF Web APIs (we are still before the merger). Another goal of the WCF Web APIs was to incorporate known concepts that would help developers to overcome some of the drawbacks they faced with WCF, such as huge configurations, overuse of attributes, and the WCF infrastructure that did not support testing well. Thus the Web APIs used IoC, enabled convention-over-configuration, and tried to offer simpler configuration environment.

The problem was that at that point in time there were several approaches for constructing HTTP services:

1. WCF with the WebHttp binding and REST support.

2. The new WCF Web APIs, soon to be ASP.NET Web APIs.

3. A not-so-new framework, ASP.NET MVC, which took a break from being HTML-oriented (getting requests from HTML pages and returning HTML/JSON) to being Resource-oriented – people started realizing that they can consider controllers as services and use the MVC infrastructure to define the control requests, responses, and better control the HTTP message.

4. Open source frameworks such as OpenRasta and ServiceStack.

In addition to that, as time passed, the WCF Web APIs had a lot of trouble adapting WCF to the “native” HTTP world. As WCF was primarily designed for SOAP-based XML messages, and the “open-heart” surgery that was required to make the Web API work as part of WCF was a bit too much (or so I understand from people who were involved in creating the Web APIs). On the other hand, the ASP.NET MVC infrastructure with its elegant handling of HTTP requests and responses, and its support of easy-to-create controllers seemed like the proper way to go for creating this new type of services.

So the fact was we had too many options and therefore too much confusion. What were we to do? We merge teams! (Kind of reminds us of the time of LINQ-to-SQL and Entity Framework, WCF and Ado.Net Data Services and other such examples). So the WCF team and the ASP.NET team joined forces and created a new framework focused on the world of REST/Hypermedia/HTTP services for the web world and thus came out the ASP.NET Web APIs.

I’m still not so sure about the choice of names, as the new Web APIs can also work outside of ASP.NET with the use of WCF, but I guess that the name “WCF ASP.NET Web API” was a bit long. Maybe “WASP Web API”? “WAWAPI” (Wcf Aspnet Web API)? Or maybe simply call it “Hypermedia Web API”?

So this merger is intended to reduce confusion, not induce it. I guess that if it was explained at that time, it might have caused less confusion over time (see the Silverlight is dead slip of PDC 2010). Does Microsoft need a new DevDiv PR team?

Is there still use for WCF? when should I choose Web APIs over WCF?

Recall my points from before - HTTP is a lot more than a transport protocol; use SOAP across the board and consider HTTP as no more than another way to pass messages.

If your intention is to create services that support special scenarios – one way messaging, message queues, duplex communication etc, then you’re better of picking WCF
If you want to create services that can use fast transport channels when available, such as TCP, Named Pipes, or maybe even UDP (in WCF 4.5), and you also want to support HTTP when all other transports are unavailable, then you’re better off with WCF and using both SOAP-based bindings and the WebHttp binding.
If you want to create resource-oriented services over HTTP that can use the full features of HTTP – define cache control for browsers, versioning and concurrency using ETags, pass various content types such as images, documents, HTML pages etc., use URI templates to include Task URIs in your responses, then the new Web APIs are the best choice for you.
If you want to create a multi-target service that can be used as both resource-oriented service over HTTP and as RPC-style SOAP service over TCP – talk to me first, so I’ll give you some pointers.

I hope this helped you removing some of the confusion over this topic.

What’s new in WCF 4.5? WebSocket support (Part 1 of 2)

Ido Flatow — Thu, 01 Mar 2012 14:12:43 GMT

This is the 11th post in the WCF 4.5 series. The previous post was about the new UDP transport support, and this new post is also about new transports – the WebSocket transport.

This post is part 1 of 2. This post will be about the WebSocket support between .NET apps using WCF (SOAP-based), and the next post will be about using WebSockets between browsers and WCF (non-SOAP).

1. What’s new in WCF 4.5? let’s start with WCF configuration

2. What’s new in WCF 4.5? a single WSDL file

3. What’s new in WCF 4.5? Configuration tooltips and intellisense in config files

4. What’s new in WCF 4.5? Configuration validations

5. What’s new in WCF 4.5? Multiple authentication support on a single endpoint in IIS

6. What’s new in WCF 4.5? Automatic HTTPS endpoint for IIS

7. What’s new in WCF 4.5? BasicHttpsBinding

8. What’s new in WCF 4.5? Changed default for ASP.NET compatibility mode

9. What’s new in WCF 4.5? Improved streaming in IIS hosting

10. What’s new in WCF 4.5? UDP transport support

A (very) short introduction to WebSockets – WebSocket is a bi-directional (two-way), full-duplex channel. WebSocket channels start as normal HTTP channels, and then use handshakes to upgrade the channel to WebSocket, allowing two-way TCP communication between client and server, thus overcoming several limitations enforced by firewalls. In order not to repeat all that is already written about WebSockets, I suggest you check the following websites:

http://en.wikipedia.org/wiki/WebSocket

http://websocket.org/

https://datatracker.ietf.org/doc/rfc6455/

Note: This post was written according to the WebSocket support of WCF 4.5 with .NET 4.5 Beta and Visual Studio 11 Beta. If you are still using the Developer Preview version, you might see some different configuration sections and different behavior of the “Add Service Reference” feature.

The support of WebSocket in WCF 4.5 is achieved through the new NetHttpBinding. The NetHttpBinding was first introduced in the WCF 4 samples as a custom binding that uses binary-encoded SOAP messages over HTTP(S). The NetHttpBinding in WCF 4.5 is an improved binding that uses binary-encoded SOAP messages over HTTP(S) or WebSocket transports. The NetHttpBinding can be used in any of the following ways:

Request-Response over HTTP. This mode does not use WebSockets, but rather a simple HTTP/HTTPS channel with binary-encoded SOAP messages.
This mode is the default mode when using the binding without a duplex contract.
Duplex over WebSocket. This mode uses WebSockets, and allows two-way communication between client and service.
This mode is automatically used when you declare your service contract with a callback contract (duplex).
Request-Response over WebSocket. This mode uses WebSockets, but it does not take advantage of the two-way communication support of the channel (since we still use the request-response pattern).
This mode is used when doing one of the following:
1. Changing the SessionMode of the contract to Required. The binding will upgrade automatically from HTTP to WebSocket, since HTTP is not sessionful and WebSocket is.
2. Manually forcing WebSocket by changing the binding configuration and setting the WebSocket transport usage to Always.

Since WebSocket is sessionful, you automatically get session support in your service, if you haven’t changed the instance context mode from the default PerSession setting. If you’ve ever needed a sessionful HTTP channel and had to use WsHttpBinding with WS-ReliableMessaging, you now have another option which doesn’t require passing extra WS-RM messages.

NetHttpBinding with WebSocket can in fact replace the use of WsDualHttpBinding, since WebSocket provides a duplex channel which also supports sessions – this is better than WsDualHttpBinding which uses two channels, and require the use of WS-ReliableMessaging for session management.

All three modes of the binding are non-interoperable, because they use binary-encoded SOAP messages which is a proprietary Microsoft encoding technique. If you want to learn more about binary encoding, I suggest you read Nicholas Allen’s posts on the subject. However, this does not mean we cannot use WebSockets as an interoperable transport with text-based SOAP messages – we can change the binding configuration to use text instead of binary, thus making in interoperable, as shown later on.

To demonstrate the usage of NetHttpBinding, I’ve created a simple duplex contract:

[ServiceContract(CallbackContract=typeof(IDuplexCallbackContract))]
public interface IDuplexContract
{
    [OperationContract]
    string SayHelloDuplex(string name);
}

[ServiceContract]
public interface IDuplexCallbackContract
{
    [OperationContract]
    void SayingHello(string message);
}

And a service that implements the contract:

[ServiceBehavior(ConcurrencyMode = ConcurrencyMode.Reentrant)]
public class WebSocketSampleService : IRegularContract, IDuplexContract
{
    public string SayHelloDuplex(string name)
    {
        OperationContext.Current.
            GetCallbackChannel<IDuplexCallbackContract>().
            SayingHello("Hello " + name + " by WebSockets");

        return "Hello " + name;
    }
}

The endpoint configuration is quite simple:

<endpoint address="http://localhost:8083"
          binding="netHttpBinding"
          contract="Contracts.IDuplexContract"/>

Note: It appear that the WCF Service Configuration Editor doesn’t recognize the NetHttpBinding’s WebSocket configuration, so you’ll need to use Visual Studio’s XML editor (the binding configuration is supported from VS11 Beta).

And as for the client-side code, just add a service reference and call the service:

Services.IDuplexContract duplexProxy;
Console.WriteLine("Press enter when service is ready");
Console.ReadLine();

// Use the generated proxy class
duplexProxy = new Services.DuplexContractClient(
    callbackContext,
    "DuplexContract");
Console.WriteLine("Calling the duplex contract:");
Console.WriteLine(duplexProxy.SayHelloDuplex("ido"));

// Or use a DuplexChannelFactory
DuplexChannelFactory<Services.IDuplexContract> dchf =
    new DuplexChannelFactory<Services.IDuplexContract>(
        callbackContext,
        new NetHttpBinding(),
        new EndpointAddress("http://localhost:8083/"));
duplexProxy = dchf.CreateChannel();
Console.WriteLine("Calling the duplex contract using text encoded messages:");
Console.WriteLine(duplexProxy.SayHelloDuplex("ido"));

Note: When specifying the endpoint address in the service, you need to use the http:// scheme, but on the client-side you can use either http:// or ws://. When generating a service reference, the client configuration will use the ws:// scheme.

Note: If your service endpoint uses NetHttpBinding but you contract is a non-duplex service contract (without a callback contract), you can still use NetHttpBinding, but the channel will be HTTP and not WebSockets – in this case the generated client configuration will create a custom binding instead of NetHttpBinding. The custom binding is a perfect match of the NetHttpBinding so things will still work, but it may be a bit confusing the first time you see it. I hope this will be resolved in the RTM version of VS 11.

When you add a service reference to the service, the client side configuration will be generated with a custom binding instead of the NetHttpBinding - you can either leave it as-is, or remove the custom binding and rewrite the configuration to use the NetHttpBinding (of course you might need to do it again when you update the service reference).

It is also quite easy to define a new service endpoint which uses the NetHttpBinding with text-based SOAP messages instead of binary:

<service name="Host.WebSocketSampleService">
    <endpoint address="http://localhost:8084"
              binding="netHttpBinding"
              bindingConfiguration="TextOverWebSockets"
              contract="Contracts.IDuplexContract"/>
</service>
<bindings>
  <netHttpBinding>
    <binding name="TextOverWebSockets" messageEncoding="Text"/>
  </netHttpBinding>
</bindings>

So as you can see, we have the ability to use both binary and text, but how can we be sure it actually passes text instead of binary? for that we need a network sniffer that can show us the WebSocket messages. You can use Wireshark or any other TCP sniffer to check that, however I always found those sniffers to be a bit hard to manage, especially for localhost communication. Luckily for us, we can use Fiddler, the famous HTTP sniffer, which now supports WebSocket messages (although only for watching).

This is how the binary message looks like when sent over WebSockets:

And this is how the text message looks like:

And this is the HTTP connection upgrade request:

(notice the GET request for WebSocket upgrade, and the corresponding HTTP 101 – Switching Protocols response)

If you want to use WebSockets for a simple Request-Response contract, you can also do that, but you’ll need to set the binding configuration of your endpoint to require WebSocket communication:

<bindings>
    <netHttpBinding>
        <binding name="ReqResWithWebSockets">
             <webSocketSettings transportUsage="Always"/>
        </binding>
    </netHttpBinding>      
</bindings>

You can download the sample code from my SkyDrive which demonstrates all of the above including duplex, request-response, sessions, forcing WebSockets, and text encoded messages.

When considering the use of WebSocket via NetHttpBinding for duplex communication vs. WsDualHttpBinding and NetTcpBinding, the benefits of NetHttpBindings are:

Like NetTcp it requires one channel instead of two, as in the case of WsDualHttp.
Like NetTcp it has a sessionful channel, unlike WsDualHttp which requires the use of WS-ReliableMessaging.
Like NetTcp, it uses binary encoding which reduces the message size, unlike the text encoding of WsDualHttp.
Unlike NetTcp, it can overcome some firewall restrictions that prohibit TCP communication.

As we’ve seen so far, the WebSocket support in WCF 4.5 uses SOAP-based messages. In the next post I will cover how to use WebSockets in WCF 4.5 to communicate with non-SOAP clients, such as web browsers, using simple text over WebSockets.

What’s new in WCF 4.5? UDP transport support

Ido Flatow — Wed, 15 Feb 2012 20:50:00 GMT

This is the tenth post in the WCF 4.5 series. I’ve started this series of posts 4 months ago when .NET 4.5 developer preview was announced; The Beta/RC/RTM version is still to come, but hopefully it will be available soon, and you will be able to use the new WCF 4.5 features in your projects.

Until now, I’ve shown new features in configuration easiness and hosting improvements. In this post and the next one I will cover new transport features, starting with the support for the UDP transport.

1. What’s new in WCF 4.5? let’s start with WCF configuration

2. What’s new in WCF 4.5? a single WSDL file

3. What’s new in WCF 4.5? Configuration tooltips and intellisense in config files

4. What’s new in WCF 4.5? Configuration validations

5. What’s new in WCF 4.5? Multiple authentication support on a single endpoint in IIS

6. What’s new in WCF 4.5? Automatic HTTPS endpoint for IIS

7. What’s new in WCF 4.5? BasicHttpsBinding

8. What’s new in WCF 4.5? Changed default for ASP.NET compatibility mode

9. What’s new in WCF 4.5? Improved streaming in IIS hosting

I’ve been teaching WCF for several years now, and almost every time I explain to people about the different types of bindings and supported transports someone asks me if there is a built-in support for a UDP transport. Until now my answer was “It isn’t supported out-of-the-box, but there is a UDP transport sample in the WCF/WF samples”. From now on my new answer is “In WCF 4/3.5 there is a sample implementation, but it is now out-of-the-box in WCF 4.5”.

You can get some basic info about the binding in the System-Provided Bindings page on MSDN (make sure you look at the 4.5 version), unfortunately there is no documentation on the UdpBinding type yet, but hopefully MS will create it by the time WCF 4.5 is released.

Declaring an endpoint that uses UDP is quite simple:

<endpoint address="soap.udp://localhost:8080/" binding="udpBinding" contract="UdpHost.IService" />

Some facts about the new UDP binding:

The address scheme for this binding is soap.udp://
The binding is supported only by .NET (since it does uses text encoding for the SOAP messages, it can be considered interoperable, although currently no other SOAP-based services technology support UDP)
Security is not supported (neither transport or message)
Sessions, transactions, streaming, and duplex are not supported (I was hoping for a duplex UDP using one-way messages)
Supported encoding is text
The binding can be used in code by adding a reference to the System.ServiceModel.Channels assembly
The binding is not supported in IIS/WAS, since there is still no UDP shared listener for WAS
In the case of One-Way messages, this is a true one-way unidirectional call - the client won’t throw an exception if the service is unavailable
If you specify a multicast address in the endpoint, such as 224.0.0.1 or 239.255.255.255 (the later is used by UDP discovery endpoints), you can create multiple listeners on the same address+protocol even from different machines – one client can send a single message that will be received by multiple listeners – this can be a great way to synchronize server state, do pub-sub (notification) calls etc...

Using a multicast listening address is also quite simple:

<endpoint address="soap.udp://239.255.255.255:8083/" binding="udpBinding" contract="UdpHost.IService" />

As for performance, I’ve create a simple client which sends 5000 messages using request-response and one-way (simple and multicast), with HTTP (basicHttp), TCP, and UDP bindings. For the purpose of the test I’ve removed all security settings from the NetTcp binding. The result is shown below:

Calling 5000 iterations one way using UDP
One-way using UDP took 0 seconds, average is 0.1792ms

Calling 5000 iterations one way using HTTP
One-way using HTTP took 6 seconds, average is 1.3ms

Calling 5000 iterations one way using TCP
One-way using TCP took 2 seconds, average is 0.5876ms

Calling 5000 iterations one way using UDP Multicast
One-way using UDP Multicast took 3 seconds, average is 0.736ms

Calling 5000 iterations of request-response using UDP
Request-response using UDP took 7 seconds, average is 1.4738ms

Calling 5000 iterations of request-response using HTTP
Request-response using HTTP took 8 seconds, average is 1.7784ms

Calling 5000 iterations of request-response using TCP
Request-response using TCP took 4 seconds, average is 0.9518ms

Conclusions:

One-way messages are fast when using UDP – about 7 times faster than HTTP, and 3 times faster than TCP. I assume this is because when using UDP we don’t need to wait for the TCP ACK (also used in HTTP).
One-way multicast messages in UDP are slower than direct messages – about 4 times slower
Request-response message in UDP are slower than TCP, but faster than HTTP. I assume the reason for being slower than TCP is that UDP uses two channels to create request-response whereas TCP requires only one channel.

Trying to run the same sample when the server has not been started produces the following results:

Calling 5000 iterations one way using UDP
One-way using UDP took 0 seconds, average is 0.1216ms

Calling 5000 iterations one way using HTTP
One-way using HTTP failed

Calling 5000 iterations one way using TCP
One-way using TCP failed

Calling 5000 iterations one way using UDP Multicast
One-way using UDP Multicast took 1 seconds, average is 0.376ms

Calling 5000 iterations of request-response using UDP
Request-response using UDP failed

Calling 5000 iterations of request-response using HTTP
Request-response using HTTP failed

Calling 5000 iterations of request-response using TCP
Request-response using TCP failed

As you can see, UDP one-way messages are unidirectional!!!

The sample code is available on my SkyDrive.

Calling a WCF service from a client without having the contract interface

Ido Flatow — Thu, 09 Feb 2012 22:47:00 GMT

I was asked yesterday in the Hebrew C#/.NET Framework MSDN forums a tough question – is it possible to dynamically call a WCF service using only the contract name, operation name, and metadata address?

At first I agreed with the answer given in the forum – move from SOAP bindings to WebHttpBinding (“REST”). This of course makes things a lot easier, only requiring you to create a WebHttpRequest and parse the response. However the question remains - is it possible to do this in the case of a SOAP-based service endpoint?

The short answer is – YES!

The full answer is – YES, but you’ll need to do a lot of coding to make it work properly, and even more coding for complex scenarios (who said passing a data contract?)

How is it done you ask?

First let’s start with the contract – you have a simple contract that looks like so:

   1:  [ServiceContract]

   2:  public interface ICalculator

   3:  {

   4:    [OperationContract]

   5:    double Add(double n1, double n2);

   6:    [OperationContract]

   7:    double Subtract(double n1, double n2);

   8:    [OperationContract]

   9:    double Multiply(double n1, double n2);

  10:    [OperationContract]

  11:    double Divide(double n1, double n2);

  12:  }

At this point the implementation doesn’t matter, but you can assume the service compiles and loads successfully.

Second, make sure your service has either a MEX endpoint or metadata exposed over HTTP GET. Read here for more info about the difference between the two.

Third – do the client coding!!! to create the client code I took some ideas from the following links:

http://msdn.microsoft.com/en-us/library/ms733780.aspx – generating client-side type information for WCF contracts

http://www.codeproject.com/Articles/42278/Call-a-Web-Service-Without-Adding-a-Web-Reference – the same concept of dynamic calls, but for ASP.NET web services (ASMX).

   1:  using System;

   2:  using System.Collections.Generic;

   3:  using System.Linq;

   4:  using System.ServiceModel;

   5:  using System.ServiceModel.Description;

   6:  using System.Globalization;

   7:  using System.Collections.ObjectModel;

   8:  using System.CodeDom.Compiler;

9:

  10:  namespace Client

  11:  {

  12:      class Program

  13:      {

  14:          static void Main(string[] args)

  15:          {

  16:              // Define the metadata address, contract name, operation name, and parameters.

  17:              // You can choose between MEX endpoint and HTTP GET by changing the address and enum value.

  18:              Uri mexAddress = new Uri("http://localhost:8732/CalculatorService/?wsdl");

  19:              // For MEX endpoints use a MEX address and a mexMode of .MetadataExchange

  20:              MetadataExchangeClientMode mexMode = MetadataExchangeClientMode.HttpGet;

  21:              string contractName = "ICalculator";

  22:              string operationName = "Add";

  23:              object[] operationParameters = new object[] { 1, 2 };

24:

  25:              // Get the metadata file from the service.

  26:              MetadataExchangeClient mexClient = new MetadataExchangeClient(mexAddress, mexMode);

  27:              mexClient.ResolveMetadataReferences = true;

  28:              MetadataSet metaSet = mexClient.GetMetadata();

29:

  30:              // Import all contracts and endpoints

  31:              WsdlImporter importer = new WsdlImporter(metaSet);

  32:              Collection<ContractDescription> contracts = importer.ImportAllContracts();

  33:              ServiceEndpointCollection allEndpoints = importer.ImportAllEndpoints();

34:

  35:              // Generate type information for each contract

  36:              ServiceContractGenerator generator = new ServiceContractGenerator();

  37:              var endpointsForContracts = new Dictionary<string, IEnumerable<ServiceEndpoint>>();

38:

  39:              foreach (ContractDescription contract in contracts)

  40:              {

  41:                  generator.GenerateServiceContractType(contract);

  42:                  // Keep a list of each contract's endpoints

  43:                  endpointsForContracts[contract.Name] = allEndpoints.Where(

  44:                      se => se.Contract.Name == contract.Name).ToList();

  45:              }

46:

  47:              if (generator.Errors.Count != 0)

  48:                  throw new Exception("There were errors during code compilation.");

49:

  50:              // Generate a code file for the contracts

  51:              CodeGeneratorOptions options = new CodeGeneratorOptions();

  52:              options.BracingStyle = "C";

  53:              CodeDomProvider codeDomProvider = CodeDomProvider.CreateProvider("C#");

54:

  55:              // Compile the code file to an in-memory assembly

  56:              // Don't forget to add all WCF-related assemblies as references

  57:              CompilerParameters compilerParameters = new CompilerParameters(

  58:                  new string[] {

  59:                      "System.dll", "System.ServiceModel.dll",

  60:                      "System.Runtime.Serialization.dll" });

  61:              compilerParameters.GenerateInMemory = true;

62:

  63:              CompilerResults results = codeDomProvider.CompileAssemblyFromDom(

  64:                  compilerParameters, generator.TargetCompileUnit);

65:

  66:              if (results.Errors.Count > 0)

  67:              {

  68:                  throw new Exception("There were errors during generated code compilation");

  69:              }

  70:              else

  71:              {

  72:                  // Find the proxy type that was generated for the specified contract

  73:                  // (identified by a class that implements the contract and ICommunicationbject)

  74:                  Type clientProxyType = results.CompiledAssembly.GetTypes().First(

  75:                      t => t.IsClass &&

  76:                          t.GetInterface(contractName) != null &&

  77:                          t.GetInterface(typeof(ICommunicationObject).Name) != null);

78:

  79:                  // Get the first service endpoint for the contract

  80:                  ServiceEndpoint se = endpointsForContracts[contractName].First();

81:

  82:                  // Create an instance of the proxy

  83:                  // Pass the endpoint's binding and address as parameters

  84:                  // to the ctor

  85:                  object instance = results.CompiledAssembly.CreateInstance(

  86:                      clientProxyType.Name,

  87:                      false,

  88:                      System.Reflection.BindingFlags.CreateInstance,

  89:                      null,

  90:                      new object[] { se.Binding, se.Address },

  91:                      CultureInfo.CurrentCulture, null);

92:

  93:                  // Get the operation's method, invoke it, and get the return value

  94:                  object retVal = instance.GetType().GetMethod(operationName).

  95:                      Invoke(instance, operationParameters);

96:

  97:                  Console.WriteLine(retVal.ToString());

  98:              }

  99:          }

 100:      }

 101:  }

I’ve placed comments that describe the code, but basically it imports the WSDL, generates types for the contract (service + data), generates C# code from it, compiles it, and uses reflection to create a proxy and invoke the correct method.

If you want to use this technique to call methods that require a data contract, you will need some extra work to create the correct type and initialize it.

A compiled and running version of this code (+ the service) can be found here: https://skydrive.live.com/redir.aspx?cid=5ef5be1ab30a6056&resid=5EF5BE1AB30A6056!466&parid=5EF5BE1AB30A6056!129

Hope you find this piece of code useful.

Feb-12:

Just found out this great blog post that uses the same implementation only to enable calling WCF services from PowerShell.
http://www.justaprogrammer.net/2012/02/11/using-powershell-to-call-a-wcf-service/

WCF/ASMX Interoperability – Removing the Annoying xxxSpecified when Adding a Web Reference to a WCF Service

Ido Flatow — Tue, 31 Jan 2012 18:22:00 GMT

Today I answered a question in the Hebrew MSDN forums about consuming WCF from a .NET 2 client, using the “Add Web Reference” option of Visual Studio.

Just in case you don’t know Hebrew I’ll sum it up for you – when adding a web reference to a WCF service that exposes a method of the following sort:

int UseScalarTypes(int value1, int value2)

The generated method signature in the client app will look like so:

public void UseScalarTypes(
  int value1, bool value1Specified, 
  int value2, bool value2Specified, 
  out int UseScalarTypesResult, out bool UseScalarTypesResultSpecified)

The question was why this happens and how this can be fixed to look like the service’s method signature.

Before we continue to see why this happens and how to fix it, the short answer is – Yes, you can make it look like the original contract by using message contracts. Continue reading to see how.

Why this happens:

In WCF the WSDL generated for the above method looks like so:

<xs:element name="UseScalarTypes">
  <xs:complexType>
    <xs:sequence>
      <xs:element minOccurs="0" name="value1" type="xs:int" /> 
      <xs:element minOccurs="0" name="value2" type="xs:int" /> 
    </xs:sequence>
  </xs:complexType>
</xs:element>

Notice the minOccurs? int is a value type which means it doesn’t accept null values, but still WCF marks it as optional. When you use the “Add Service Reference” option of WCF in Visual Studio, the generator ignores that attribute and creates the method declaration in the client side the same way it is declared in the service contract. However, if you use the old “Add Web Reference” option, the generator checks the minOccurs, realizes that the variable is optional, and since this is a value type, it translates the optional into a set of variables: value + xxxSpecified.

By the way, this is how the WSDL is created for the same method declaration when it is used in an ASMX-style web service:

<s:element name="UseScalarTypes">
  <s:complexType>
    <s:sequence>
      <s:element minOccurs="1" maxOccurs="1" name="value1" type="s:int" /> 
      <s:element minOccurs="1" maxOccurs="1" name="value2" type="s:int" /> 
  </s:sequence>
  </s:complexType>
</s:element>

Note 1: With ASMX web service, the minOccurs/maxOccurs is set properly because the “Add Web Reference” expects that, and therefore we don’t see this behavior with ASMX web service + add web reference.

Note 2: Since WCF ignores the minOccurs, using the “Add Service Reference” to consume that ASMX web service will result in a client-side method with the same signature as declared in the service (without the xxxSpecified).

So now that we know why this happens, let’s see how to fix it.

Step 1: Create a set of message contracts, one for the request and one for the response (if you have one).

Step 2: In the request message contract class, apply the MessageContract attribute and set the IsWrapped parameter to false, like so:

[MessageContract(IsWrapped = false)]
public class UseScalarTypesRequest

Setting the IsWrapped to false will create the XML without a wrapping element, making the properties look like they are actually method parameters.

Step 3: Add each parameter of the method to the class as a property, and apply the MessageBodyMember attribute to it. You can use this step to rename the property to use the naming convention of parameters by using the Name parameter in the attribute. The result should look like so:

[MessageContract(IsWrapped = false)]
public class UseScalarTypesRequest
{
  [MessageBodyMember(Name = "value1")]
  public int Value1 { get; set; }
  [MessageBodyMember(Name = "value2")]
  public int Value2 { get; set; }
}

Step 4: Do the same for the response message contract, this time you just need one property for the return type of the method, for example:

[MessageContract(IsWrapped = false)]
public class UseScalarTypesResponse
{
  [MessageBodyMember]
  public int Result { get; set; }
}

Step 5: Change the method signature in the contract and service from using parameters to using the message contracts you’ve created, like so:

UseScalarTypesResponse UseScalarTypes(UseScalarTypesRequest parameters)

Of course the immediate step will be to also change the implementation of your code to reflect the parameters being moved to a wrapper object - for convenience, you can leave your existing code in the service as is, change the contract, and then create the new methods which will simply call the older ones, like so:

UseScalarTypesResponse UseScalarTypes(UseScalarTypesRequest parameters)
{
  UseScalarTypesResponse result = new UseScalarTypesResponse();
  result.Result = UseScalarTypes(parameters.Value1, parameters.Value2);
  return result;
}

That’s it, update your web reference in the client side, and watch how the method signature in the client side is without the xxxSpecified.

פורום חדש לתחום ווב נפתח בפורומי מיקרוסופט ישראל

Ido Flatow — Sat, 28 Jan 2012 19:40:39 GMT

לפני מספר חודשים נפתחו באתר מיקרוסופט MSDN ישראל פורומים לפיתוח ו-IT. בחודש האחרון חל שינוי בפורומים, בקטלוג שלהם, וברשימת מנהלי הפורומים. כחלק מהשינוי אני שמח לבשר לכם על פתיחתו של פורום חדש לתחום הווב בניהולם של שלמה גולדברג (הרב דוטנט) ועבדכם הנאמן.

בפורום ננסה לתת מענה לשאלות בנושאי פיתוח לעולמות הווב של מיקרוסופט – ASP.NET, ASP.NET MVC, Web Services, WCF, IIS, HTML/JS ועוד.

להבדיל מהפורומים של MSDN, הפורומים במיקרוסופט ישראל מיועדים לקהל הישראלי, כתובים בעברית, ומעודדים כתיבה בעברית של שאלות ותשובות.

למה בעברית? למה פורומים נוספים על אלו של MSDN? ובכן:

1. אנחנו לא היחידים – להרבה מדינות יש פורומים מקומיים, בשפה מקומית, שמיועדים לקהל המקומי.

2. עברית כשפת אם - לחלקנו קל להתבטא יותר בעברית במקום באנגלית. אני מכיר מפתחים מצויינים שעדין משתמשים בבודק איות לפני שליחת מייל באנגלית. כתיבה בעברית גם מאפשרת גישה לפורומים לקהל היותר צעיר של מפתחים.

3. יצירת קהילה – השתתפות בפורום תאפשר שיתוף פעולה יותר הדוק בין הקהל הישראלי והנציגים בארץ של מיקרוסופט. דרך הפורום נוכל ליידע אתכם על הרצאות בבתים פתוחים, כנסים בארץ,קורסים והכשרות. במקרים מסוימים ייתכן ואף נוכל לבצע אסקלציה של שאלות לגורמים במיקרוסופט ישראל ואף יותר מכך.

לצערנו, עד כמה שנרצה, פורום לא יכול להסתמך אך ורק על המנהלים שלו שיענו, ולכן ההשתתפות שלהם חיונית להצלחת הפורום. אז גם אם אין לכם שאלה ספציפית, אתם מוזמנים להכנס לפורום מדי פעם, להגיב על שאלות, ללמוד משאלות של אחרים, וגם לספר לנו על משהו מעניין שמצאתם שאולי יכול לשמש אנשים אחרים. אם אתם נוהגים לעבוד עם RSS, אתם מוזמנים להוסיף את לינק ה-RSS של הפורום לרשימות שלכם.

אז נתראה בפורום, בבלוג, בטוויטר ובאירועים השונים השנה.

What’s new in WCF 4.5? Improved streaming in IIS hosting

Ido Flatow — Tue, 17 Jan 2012 20:36:00 GMT

As promised in my previous post, I’m continuing my mission to inform you of new changes in WCF 4.5.

This is the ninth post in the WCF 4.5 series. This post continues the previous posts on web-hosting features, and this time it is about the improved streaming capabilities of WCF when it is hosted in IIS.

1. What’s new in WCF 4.5? let’s start with WCF configuration

2. What’s new in WCF 4.5? a single WSDL file

3. What’s new in WCF 4.5? Configuration tooltips and intellisense in config files

4. What’s new in WCF 4.5? Configuration validations

5. What’s new in WCF 4.5? Multiple authentication support on a single endpoint in IIS

6. What’s new in WCF 4.5? Automatic HTTPS endpoint for IIS

7. What’s new in WCF 4.5? BasicHttpsBinding

8. What’s new in WCF 4.5? Changed default for ASP.NET compatibility mode

If you’ve ever tried creating a WCF service that uses streamed requests (for example a file upload service) and host it in IIS, you may have noticed a strange behavior in your WCF service – it would seem that WCF is late in receiving the request, as if it was entirely loaded into the memory, and then passed to WCF. So is it streamed? or is it actually buffered? well, it’s both.

When you host a WCF service in IIS you also get a bit of the ASP.NET pipeline on the side, even if you don’t use the ASP.NET compatibility mode, this is documented in the WCF Services and ASP.NET article on MSDN (look for the part about the PostAuthenticateRequest event). In .NET 4, there is a design flaw in ASP.NET which causes the requests sent to WCF to be buffered in ASP.NET. This buffering behavior causes several major side-effects:

1. There is a latency between the time the streamed message is received by ASP.NET and the time the WCF service method is actually invoked.

2. There is some memory consumption due to the buffering – the exact amount of memory consumed depends on the size of the message sent by the client, but it can even get to several hundred MBs if you increase the MaxRequestLength of ASP.NET, the MaxAllowedContentLength of IIS 7, and of course the MaxReceivedMessageSize and MaxBufferSize of WCF.

3. When ASP.NET buffers the request, it uses both memory and disk. The requestLengthDiskThreshold configuration setting of ASP.NET controls when ASP.NET starts to use the disk. If you upload multiple files to WCF at once, you will start to see some delays due to multiple files being written to the disk at once. BTW, the files are written to an “upload” folder under the web application’s temporary asp.net folder (under c:\windows\Microsoft.NET\Framework\vX.X.XXXX\Temporary ASP.NET Files\) and are removed after the request is handled.

To show this behavior, I have created a client application that uploads a 500MB file to a WCF service. The WCF service is hosted in IIS and is set to a streamed request (you can download the StreamingInIIS sample solution from here). The following output shows some information about the time it took for the service to receive and handle the request, and the consumed memory:

1 Client started upload on 17/01/2012 19:03:25
2 Available memory before starting is: 2701MB
3 Client finished upload on 17/01/2012 19:03:44
4 Available memory after finishing is: 2699MB
5 Available memory on ASP.NET is: 2701MB
6 ASP.NET received upload at: 17/01/2012 19:03:28
7 Available memory on WCF is: 2122MB
8 WCF started receiving file at: 17/01/2012 19:03:38
9 WCF finished receiving file at: 17/01/2012 19:03:43
File size is: 524288000
Press any key to continue . . .

Some things to note about these results:

1. Client started / Client finished (line 1+3) – the total time the client waited for the service was 19 seconds; this includes the upload time, the buffering time of ASP.NET, and the time WCF handled the received stream.

2. ASP.NET started receiving the stream 3 seconds after the client began sending it (line 6).

3. WCF started receiving the stream 10 seconds after ASP.NET received started receiving it, and a total of 13 seconds from the time the client started sending it (line 8). In total, it took WCF 5 seconds to read the entire stream from ASP.NET (line 8+9).

4. Before the client sent the message, the available memory in the machine was 2701MB, which is also the available memory when ASP.NET first received the message. By the time WCF got the request and started handling it, the available memory was 2122MB – about 580MB were consumed from the memory for this operation (lines 2, 5, and 7).

5. As for the generated temp file, here is a screenshot of the temporary ASP.NET folder content:

Note: to show the ASP.NET information I used the ASP.NET compatibility mode. You can turn it off in the sample code if you want to verify that the problem also exists when we don’t use the compatibility mode (look at the difference between the time the client sent the request and the time WCF actually started handling the request – there should be a big latency).

So we get that WCF 4 doesn’t handle well streamed content over IIS, but what about WCF 4.5? what has changed?

In WCF 4.5 this just doesn’t happen – with .NET 4.5, ASP.NET doesn’t buffer the request, but rather forwards it directly to WCF, so we don’t get any latency, no memory consumption, and no disk usage.

Want to see some proof? I ran the same demo code in Windows Server 8 with WCF 4.5 over IIS. I used a smaller file size (200MB), since this is a VM with less memory, however you can still see the difference quite clearly:

1 Client started upload on 11/27/2011 7:23:18 AM
2 Available memory before starting is: 942MB
3 Client finished upload on 11/27/2011 7:23:46 AM
4 Available memory after finishing is: 942MB
5 Available memory on ASP.NET is: 941MB
6 ASP.NET received upload at: 11/27/2011 7:23:20 AM
7 Available memory on WCF is: 942MB
8 WCF started receiving file at: 11/27/2011 7:23:20 AM
9 WCF finished receiving file at: 11/27/2011 7:23:46 AM
File size is: 209715200
Press any key to continue . . .

First thing to note – memory consumption hasn’t changed throughout the execution – remains steady at ~942MB (lines 2+4+5+7).

As for the latency – WCF received the request at the same time ASP.NET received it (lines 6+8), which is 2 seconds after the client begins sending it.

Oh, and since ASP.NET passed the stream directly to WCF, no temp file was created !!

So there you have it – proper streaming in WCF 4.5 over IIS.

Stay tuned for more posts about the new features of WCF 4.5. You can also follow me on Twitter (@IdoFlatow) to get updates as soon as new posts are published.

Dear blog, it’s been a while since my last post

Ido Flatow — Sun, 15 Jan 2012 23:16:46 GMT

If you’ve been wondering where I disappeared to in the last couple of weeks, and if you are still waiting anxiously for my next post about WCF 4.5, fear not, I’m here, I’m alive, and I’m still kicking.

It’s been quite a rough month, as I have been occupied knee deep in home renovations. If you’ve ever dealt with contractors, technicians, and handyman, you know the type of frustration I’m talking about.

Between re-tiling my floors, replacing my kitchen cabinets, and re-painting my entire home, I also managed to find the time to deliver some courses on Windows Azure, IIS, Advanced WCF, Windows HPC Server, AppFabric Cache, and PowerShell.

2012 is going to be very productive year – this year is going to be a lot about the new releases of .NET 4.5, VS11, and Windows Server 8. I’m guessing you’ll see many more posts about the new features of WCF 4.5 (soon to come – a new post about the new streaming features of WCF 4.5 over IIS), .NET 4.5, and VS11.

I’m also continuing my voyage with BigData solutions which I’ve started last year with my work on the Windows HPC Server 2008 R2, and the new HPC labs we’ve created in Sela for the Windows Azure Platform Training Kit. This year is mostly going to be about Hadoop on Azure, so expect new labs and demos soon on the WAP TK (Windows Azure Platform Training Kit).

This year I will continue to manage the Israeli Web Developer Community (WDCIL) along with Gal Kogman, and in a couple of days I will also start to moderate the WebDev IL MSDN forum with Sholomo Goldberg, AKA the DotNet Rabbi.

I’m also continuing my speaking engagements this year, which ended last year with my sessions at VSLive Redmond and MCT Summit in October and VSLive Orlando in December. Other than my usual appearances at Sela’s SDP conferences in Israel, I will also be speaking this April in the Great Indian Developer Summit (GIDS) in Bangalore (India of course), and hopefully in additional conferences in Europe and the US (more information to come in the next couple of weeks).

So check out for my posts, my tweets, my courses, and my speaking engagements, and don’t forget – if you need me, just turn on the bat signal, and I’ll come to your rescue, just kidding – you can always contact me through my blog, my tweeter account, or send me an email, and I’ll do my best to answer you promptly.

Happy new year to y’all, enjoy the new leap year, and hopefully we’ll still be here to see 2013.

Slide decks and demo code from my Visual Studio Live 2011 (Orlando) sessions

Ido Flatow — Wed, 07 Dec 2011 21:22:28 GMT

Yesterday I had two session in VS Live, one about the new features of WCF 4, and the other about the new way to develop web applications using ASP.NET MVC, the Razor view engine, jQuery, and IIS 7.5 Express.

The slide decks and demo code for both sessions can be downloaded from here: http://bit.ly/vslive-2011-orlando

I really enjoyed delivering both sessions, and congratulations to all the people that won Angry Bird balls for answering my questions, and for asking tough questions.

Hopefully we will meet in next year’s VSLive (if my sessions are picked up again).

Creating your own (customized) standard endpoints in WCF 4

Ido Flatow — Wed, 07 Dec 2011 21:10:00 GMT

Lately I’ve been writing and speaking a lot about WCF 4.5, but while delivering my “What’s new in WCF 4” session in Visual Studio Live yesterday I realized that there is one feature of WCF 4 that most people are not aware of, and do not really understand how useful it is – Standard Endpoints.

In WCF we always have to specify a set of address+binding+contract (ABC) for our endpoints. If our endpoints also need to be configured, for example – change the binding configuration, or the endpoint behavior, then we need to add some more configuration. We can use default configuration (another feature of WCF 4), but if we have two common settings, we cannot set two defaults and we’re back to square one.

Standard endpoints change the way we define endpoints – with standard endpoints we specify a special “kind” name in our endpoint, which automatically sets our endpoint’s address, binding, contract, binding configuration, and endpoint behavior.

For example – if we define the following endpoint:

<endpoint address="mex" kind="mexEndpoint"/>

The above endpoint will automatically be set with the mexHttpBinding and the IMetadataExchange contract.

If we define the following endpoints:

<endpoint address="web" kind="webHttpEndpoint" contract="MyNS.IMyContract"/>

We will get an endpoint which uses webHttpBinding, and automatically gets the webHttp endpoint behavior.

Although this is quite nice, this is the least we can do with standard endpoints. The real use of standard endpoints is when you create some of your own.

Image the following – you are a part of an infrastructure team in your organization and you need to explain to the dev teams which endpoint configuration they should use in their projects – “Please use NetTcp binding, with increased message size limits, with either security none or transport, and don’t forget to increase the send timeout”.

One way to do this is to send a memo to all the dev teams, hoping everyone follow your instructions to the letter. Another way you can do that is to create your own standard endpoint with all of the above configuration and just send it to the dev teams to use.

First of all you need to create your custom endpoint:

   1:  public class CompanyNameStandardEndpoint : ServiceEndpoint

   2:  {

   3:      private bool _isSecured;

4:

   5:      public CompanyNameStandardEndpoint(ContractDescription contract)

   6:          : base(contract)

   7:      {

   8:          this.Binding = new NetTcpBinding();

   9:          ResetBindingConfiguration(this.Binding);

  10:          this.IsSystemEndpoint = false;

  11:      }

12:

  13:      public bool IsSecured

  14:      {

  15:          get

  16:          {

  17:              return _isSecured;

  18:          }

  19:          set

  20:          {

  21:              _isSecured = value;

  22:              if (_isSecured)

  23:              {

  24:                  (this.Binding as NetTcpBinding).Security.Mode = SecurityMode.Transport;

  25:              }

  26:              else

  27:              {

  28:                  (this.Binding as NetTcpBinding).Security.Mode = SecurityMode.None;

  29:              }

  30:          }

31:

  32:      }

33:

  34:      // Receive a dynamic object instead of creating separate methods

  35:      // for netTcp, basicHttp, WSHttpBinding...

  36:      private void ResetBindingConfiguration(dynamic binding)

  37:      {

  38:          binding.SendTimeout = TimeSpan.FromMinutes(5);

  39:          binding.MaxReceivedMessageSize = Int32.MaxValue;

  40:          binding.MaxBufferSize = Int32.MaxValue;

  41:      }

  42:  }

Line 8 makes sure that your endpoint will use NetTcp binding.

Line 9 will call a method that initializes the binding settings (lines 36-41).

Note : the ResetBindingConfiguration method receives a dynamic object because for some reason some of the binding properties such as the MaxReceivedMessageSize and the MaxBufferSize are defined in each of the bindings instead of being defined in a base Binding class. The dynamic will allow us to change our code later on to support both TCP and HTTP bindings without duplicating our method for overloads.

Line 10 specifies that this is a user-defined endpoint and not a system endpoint.

Lines 13-32 are responsible of handling the user’s selection to whether the endpoint is secured or not by changing the security mode to either Transport or None.

So now we have a new standard endpoint that initializes the binding to NetTcpBinding, sets the timeout and message size, and knows to set the security according to the user’s selection. We can now add this endpoint in code to our service by calling the following code:

   1:  CompanyNameStandardEndpoint newEndpoint = new CompanyNameStandardEndpoint(

   2:          ContractDescription.GetContract(typeof(IService1)));

3:

   4:  newEndpoint.IsSecured = false;

   5:  newEndpoint.Address = new EndpointAddress(tcpBaseAddress + "companyUnsecured");

6:

   7:  host.AddServiceEndpoint(newEndpoint);

To be able to add this endpoint configuration in the config file, you will need to add some boilerplate code:

   1:  public class CompanyNameStandardEndpointCollectionElement :

   2:      StandardEndpointCollectionElement<CompanyNameStandardEndpoint, CompanyNameStandardEndpointElement>

   3:  {

   4:  }

5:

   6:  public class CompanyNameStandardEndpointElement : StandardEndpointElement

   7:  {

   8:      protected override ServiceEndpoint CreateServiceEndpoint(ContractDescription contractDescription)

   9:      {

  10:          return new CompanyNameStandardEndpoint(contractDescription);

  11:      }

12:

  13:      public bool IsSecured

  14:      {

  15:          get { return (bool)base["isSecured"]; }

  16:          set { base["isSecured"] = value; }

  17:      }

18:

  19:      protected override ConfigurationPropertyCollection Properties

  20:      {

  21:          get

  22:          {

  23:              ConfigurationPropertyCollection properties = base.Properties;

  24:              properties.Add(new ConfigurationProperty("isSecured", typeof(bool), false, ConfigurationPropertyOptions.None));

  25:              return properties;

  26:          }

  27:      }

28:

  29:      protected override Type EndpointType

  30:      {

  31:          get { return typeof(CompanyNameStandardEndpoint); }

  32:      }

33:

  34:      protected override void OnApplyConfiguration(ServiceEndpoint endpoint, ServiceEndpointElement serviceEndpointElement)

  35:      {

  36:          CompanyNameStandardEndpoint customEndpoint = (CompanyNameStandardEndpoint)endpoint;

  37:          customEndpoint.IsSecured = this.IsSecured;

  38:      }

39:

  40:      protected override void OnApplyConfiguration(ServiceEndpoint endpoint, ChannelEndpointElement channelEndpointElement)

  41:      {

  42:          CompanyNameStandardEndpoint customEndpoint = (CompanyNameStandardEndpoint)endpoint;

  43:          customEndpoint.IsSecured = this.IsSecured;

  44:      }

45:

  46:      protected override void OnInitializeAndValidate(ServiceEndpointElement serviceEndpointElement)

  47:      {

48:

  49:      }

50:

  51:      protected override void OnInitializeAndValidate(ChannelEndpointElement channelEndpointElement)

  52:      {

53:

  54:      }

  55:  }

The above code is a basic configuration element code. The most important part is lines 13-17 in which you need to repeat each of the properties you created in the custom standard element (for a mapping between XML and CLR) and line 24 where you add all the properties that can be set in the configuration file, so the configuration can be validated.

Once you create the above code, you need just on more step to use the new endpoint kind in your configuration – you need to tell WCF that you have a new service endpoint. To do that you add the following XML in your <system.serviceModel> section:

   1:  <extensions>

   2:      <endpointExtensions>

   3:          <add

   4:        name="companyNameEndpoint"

   5:        type="TestWcfStandardEndpoints.CompanyNameStandardEndpointCollectionElement, TestWcfStandardEndpoints"/>

   6:      </endpointExtensions>

   7:  </extensions>

Note: On MSDN you can find a good explanation on standard endpoints, but the extensions configuration part is incorrect, the above configuration is the correct one (the correct element in the <extensions> is <endpointExtensions> and not <standardEndpointExtensions> as it appears in the article).

Now you are ready to declare your new endpoints and configure them:

   1:  <services>

   2:      <service name="TestWcfStandardEndpoints.Service1">

   3:          <endpoint binding="basicHttpBinding"

   4:              contract="TestWcfStandardEndpoints.IService1"/>

   5:          <endpoint address="mex"

   6:              kind="mexEndpoint" />

   7:          <endpoint address="companySecured"

   8:              kind="companyNameEndpoint"

   9:              endpointConfiguration="securedEndpoint"

  10:              contract="TestWcfStandardEndpoints.IService1"/>

  11:      </service>

  12:  </services>

13:

  14:  <standardEndpoints>

  15:      <companyNameEndpoint>

  16:          <standardEndpoint isSecured="true" name="securedEndpoint"/>

  17:      </companyNameEndpoint>

  18:  </standardEndpoints>

In lines 7-10 we define the endpoint with the new “kind” (line 9) and specify where we configure the rest of the endpoint (line 10).

Lines 14-18 contains the configuration of the standard endpoint which we created.

So to conclude, standard endpoints are an easy way to create fully-configured endpoints with binding configuration, contract settings, and endpoint behaviors. It’s mostly useful when wanting to create the same endpoint over and over again in multiple projects (which happens in 99.99% of the time).

Don’t bother copy pasting all the above code – you can just download the complete solution from here

Slide decks and sample code from my WCF 4.5 open-house in Microsoft

Ido Flatow — Sun, 27 Nov 2011 22:35:39 GMT

Today I delivered a half-day talk about WCF on the following subjects:

The new features of WCF 4.5
We talked about configuration simplicity, WebSocket and UDP support, streaming fixes for IIS, binary compression, and more.
Monitoring and troubleshooting WCF services (WCF 3.5/4/4.5)
We talked about performance counters, ETW, WMI, AppFabric, sniffing tools, tracing and message logging, instancing, concurrency, load tests and more.

According to the events website at http://events.microsoft.com, it looks like this was the first Microsoft event worldwide about WCF 4.5. We like new technologies in Israel .

We had a full-house (~100 people), got a lot of questions from people during and after the session, so it was lots of fun. I really enjoyed delivering the session, and I hope that in the coming year we will be able to see the RTM of Visual Studio 11 and .NET 4.5.

If you missed today’s session, you have another chance to hear me talk about WCF 4.5 in the November meeting of the Web Developers Community (WDCIL) this Tuesday in Microsoft Raanana. You can get more information and register to the event at http://wdcil2011nov.eventbrite.com

In the meanwhile, you can download the presentation and the sample code I’ve shown from my SkyDrive at http://bit.ly/wcf45msdn – this also includes the WCF 4.5 demos I showed, so don’t forget to install VS 11 and .NET 4.5 (preferably on a VM).

I want to repeat what I told people in the event today – the WCF team is eager to know what you think about WCF, what is missing in WCF to make your work easier, and if you encountered any bugs in the product. There are several ways by which you can contact them:

For WCF 4.5

Visit the .NET 4.5 forum at: http://forums.asp.net/1239.aspx/1?ASP+NET+4+5+ASP+NET+WCF+and+Visual+Studio+11+Developer+Previews
Report an issue, feedback, or bugs on Microsoft Connect: https://connect.microsoft.com/VisualStudio

For WCF 4

Visit the WCF forum at: http://social.msdn.microsoft.com/Forums/en/wcf
Report an issue, feedback, or bugs on Microsoft Connect: https://connect.microsoft.com/wcf

If you want to read more about WCF 4.5, check out previous posts I published. I will publish new in-depth posts on the new features, so stay tuned. You can also follow me on Twitter @IdoFlatow

1. What’s new in WCF 4.5? let’s start with WCF configuration

2. What’s new in WCF 4.5? a single WSDL file

3. What’s new in WCF 4.5? Configuration tooltips and intellisense in config files

4. What’s new in WCF 4.5? Configuration validations

5. What’s new in WCF 4.5? Multiple authentication support on a single endpoint in IIS

6. What’s new in WCF 4.5? Automatic HTTPS endpoint for IIS

7. What’s new in WCF 4.5? BasicHttpsBinding

8. What’s new in WCF 4.5? Changed default for ASP.NET compatibility mode

If you want to learn more about WCF, check out the following WCF sessions we have at Sela’s DevDays next week:

WCF Crash Course - http://www.sela.co.il/s/SDP/Dec2011/tutorials2.html#d53
Advanced WCF - http://www.sela.co.il/s/SDP/Dec2011/tutorials2.html#d63

WDCIL Call for Speakers

Ido Flatow — Mon, 31 Oct 2011 21:17:34 GMT

If you are not familiar with our user group, the Israeli WDC user group is a meeting place for web developers, designers, and architects, where we discuss new and existing web technologies, best practices in web development, and any other interesting stuff that relates to the web world. The user group is managed by Gal Kogman and yours truly, with the support of Microsoft Israel.

This is just a short list of things we talked about in previous meetings:

ASP.NET MVC
Win8, HTML5, and JS libraries
jQuery mobile framework
Beyond Visual Studio 2010 – Lightswitch, NuGet, IIS Express …
Javascript and jQuery tricks
Facebook for developers
Rich application for the browser – EF, WCF, Ajax, and jQuery

You can read more about the user group on our Microsoft page (a bit outdated), and for the latest news and information, I suggest you visit our Facebook page.

So what’s the purpose of this post, you ask? I’m writing this post to let you know that we are always looking for potential speakers - the field of web development is very vast, and many of us deal with all sorts of web technologies and techniques, so if you think you have worked with a special technology you want to share with the community by presenting it in one of the meetings, please let me know by email or by writing in our Facebook wall. You don’t need to be an experienced speaker to present at the meetings, just make sure you don’t have stage freight beforehand .

What’s new in WCF 4.5? Changed default for ASP.NET compatibility mode

Ido Flatow — Mon, 31 Oct 2011 09:46:00 GMT

This is the eighth post in the WCF 4.5 series. This post continues the previous posts on web-hosting features. This post is about the ASP.NET compatibility mode default change of WCF 4.5.

1. What’s new in WCF 4.5? let’s start with WCF configuration

2. What’s new in WCF 4.5? a single WSDL file

3. What’s new in WCF 4.5? Configuration tooltips and intellisense in config files

4. What’s new in WCF 4.5? Configuration validations

5. What’s new in WCF 4.5? Multiple authentication support on a single endpoint in IIS

6. What’s new in WCF 4.5? Automatic HTTPS endpoint for IIS

7. What’s new in WCF 4.5? BasicHttpsBinding

Normally, a WCF service hosted under IIS works side-by-side with ASP.NET – they share some of the pipeline, they have the same application domain, but work quite independently of each other when it comes to the HTTP context (authorization, context, session, etc…). This is the default behavior of WCF.

However, you can change the default behavior of WCF and set it to ASP.NET compatibility mode – this allows WCF and ASP.NET to share most of the pipeline, and have the same HTTP context. This has some advantages and some disadvantages (such as the problem of ASP.NET sessions and blocking WCF calls).

To make WCF use the ASP.NET compatibility mode you need to do the following two changes:

1. Enable ASP.NET compatibility mode for the hosting environment in your web.config:

<system.serviceModel>
        <serviceHostingEnvironment aspNetCompatibilityEnabled="true" />    
</system.serviceModel>

2. Set each of your services to support the compatibility mode, by adding the AspNetCompatibilityRequirements attribute.

[AspNetCompatibilityRequirements(RequirementsMode = AspNetCompatibilityRequirementsMode.Allowed)]

You can read more about WCF and ASP.NET on MSDN.

So what has changed in WCF 4.5?

In WCF 4.5 the default behavior of WCF is to support the ASP.NET compatibility mode automatically. This is achieved by the following changes:

1. In the WCF Service Application project template, the aspNetCompatibilityEnabled attribute was added to the serviceHostingEnvironment element, and it is set to true by default.

2. The default value of the AspNetCompatibilityRequirements attribute has changed from NotAllowed to Allowed. Without this changed default, you would have needed to manually add the attribute to every new service. This is noticeable in the attribute’s documentation:

WCF 4 - http://msdn.microsoft.com/en-us/library/system.servicemodel.activation.aspnetcompatibilityrequirementsattribute.requirementsmode(v=VS.100).aspx

WCF 4.5 - http://msdn.microsoft.com/en-us/library/system.servicemodel.activation.aspnetcompatibilityrequirementsattribute.requirementsmode(v=VS.110).aspx

ASP.NET compatibility mode is very useful if you need to use share information between your ASP.NET application and WCF service in regards to the HTTP context, session, or user authorization, but be careful of the concurrency problem that occurs when sharing session state between WCF and ASP.NET.

Expect more on ASP.NET and WCF in next posts, so stay tuned. You can also follow me on Twitter (@IdoFlatow) to get updates as soon as new posts are published.

The RTM of .NET 4.5 is still to come, and I assume many of you are still adjusting to WCF 4. If you want to learn more about the new features of WCF 4, come to my session at Visual Studio Live! 2011 in Orlando (December 5-9).