Ido Flatow's Blog

Veni Vidi Scripsi

Wrapping up October’s conferences

Ido Flatow — Mon, 14 Oct 2013 12:02:05 GMT

It’s mid-October and I’m already warn down after two weeks of conferences. My October began in Las Vegas with DevConnections where I had a workshop and four sessions, continued with a 72-hour stop back home in Israel for some father-son time (with my son of course, not with my father), and then another week in London with Software Architect where I had a workshop and a session. Now I’m back home, relaxing, working, and preparing for my next conference in December, this time in Israel at the SDP (Sela Developer Practice) conference.

In case you didn’t attend my sessions, no worries, I have links to both the slides and the code samples right here:

ASP.NET Web API and HTTP Fundamentals workshop (code is available here)

Automating Windows Azure (code is available here)

Caching in Windows Azure (code is available here)

Debugging with Fiddler (code is available here)

If you’ve been to my session, enjoy your new Fiddler T-shirts.

IIS for Developers (code is available here)

Advanced WCF Workshop (code is available here)

What's New in WCF 4.5 (code is available here)

Enjoy.

Speaking at DevConnections 2013

Ido Flatow — Mon, 26 Aug 2013 07:13:11 GMT

If you’ve read my post from last week, you know that I went off the grid for 8 months, mostly because I was working on authoring yet another course for Microsoft (20487 – Developing Windows Azure and Web Services), but also partially because of my new baby boy, who made sure my laptop stays closed when I’m at home. Now that my baby is a couple of months old, I can start my conference rotation for 2013, starting with DevConnections.

Speaking at DevConnections is going to be a great experience for me, for several reasons:

1. It’s my first out-of-the-country conference for 2013.

2. It’s my first time speaking in DevConnections.

3. I’m going to have four (!!) sessions and a workshop, which makes me the most-often appearing speaker at the conference. How’s that for stressful?

4. It’s the first time I’ll be doing a workshop in such a conference (don’t get me wrong on this, I’ve trained courses for several years in Israel and abroad, and had workshops in local conferences in Israel, but still, doing a 1-day workshop in a big conference in the US is a bit challenging).

So what will you learn if you attend my sessions? Let’s see.

ASP.NET Web API and HTTP Fundamentals (Pre-conference workshop, Monday)

The purpose of this workshop is twofold: going over the fundamentals of HTTP, and learning how to apply these concepts with ASP.NET Web API.

Isn’t HTTP something every developer knows of? You have request and response, GET and POST, what else is there to know? Well, you’ll be surprised: status codes, verbs, content negotiation, caching, compression, concurrency, security, streaming, and connectivity. We’ll also learn how Windows handles HTTP communication, how you can configure HTTP with IIS, and how to debug your HTTP communication with Fiddler.

As I mentioned, the purpose of the workshop is twofold – and the best way to learn about HTTP is to implement HTTP-based services with ASP.NET Web API. During the workshop we’ll learn how to use ASP.NET Web API to create services, how to configure routing templates, how to handle response headers, content negotiation with Media Type Formatters, validation and exception handling with action filters, request manipulation and security with delegating handlers, and more. We’ll also learn how to create OData services to better handle our data, and how to consume services from .NET applications and JavaScript, using jQuery.

Why should you attend this workshop? because I believe you cannot learn how to use ASP.NET Web API without first understanding the capabilities of HTTP.

If you need to convince your boss why you should attend this workshop, maybe these two facts can come in handy:

1. Registering to the workshop is cheaper than a 3-day ASP.NET Web API course, but you’ll get all your essentials and more in this 1-day workshop.

2. The workshop is delivered by a Microsoft MVP, the author of Microsoft’s official ASP.NET Web API course (20487B - developing Windows Azure and Web Services).

Automating Windows Azure from the Command Line (75-minute session. Tuesday, 10:00 AM)

I have nothing against the Windows Azure Management Portal, it has a slick UI, it’s easy to use, informative, and enables you to do most of what you need. But let’s face it - when you need to create a virtual network with five VMs, configure each VM, deploy your application to it, and repeat this for each of your customers, you don’t use the portal.

Luckily, the Windows Azure Service Management has various HTTP APIs for you to use, and even better than that, those APIs are accessible through PowerShell cmdlets, and cross-platform CLI (Command-Line Interface) tools you can use on Linux, Mac, and Windows.

In this session, we will understand the process of automating Windows Azure operations, and see how to use the PowerShell cmdlets and the Windows Azure CLI to accomplish automation tasks, such as creating virtual networks, virtual machines, web sites, and cloud services.

Why should you come to this session? Simple, you’ll get lots of script examples you can take back to the office.

Debugging the Web with Fiddler (75-minute session. Tuesday, 2:30PM)

Well, where should I begin?! Answer this simple question – do you develop Web applications? Web services (ASMX/WCF/WebAPI)? Desktop apps that consume services over HTTP? If you answered yes to one or more questions, then you need to know how to use Fiddler.

Most people think of Fiddler as an HTTP sniffing tool, but the truth is that fiddler is a lot more than that. Fiddler is a Web debugging tool. We use it to debug both our client-side and server-side code, to better test our application, to improve the performance of our code, and support our customers when they face network errors.

In this session, we will learn how to use the different features of Fiddler to accomplish those tasks. If everyone leave this session wanting to install Fiddler, it means I did my part.

Why should you come to this session? If you don’t know what Fiddler is, or only heard of it, you have no other choice. If you do know how to use Fiddler, come to the session, maybe (probably) you’ll learn something new.

Caching in Azure: There’s More to That Than Azure Caching (75-minute session. Tuesday, 4:15PM)

Caching, especially distributed caching, is part of every scalable application architecture. You can’t build large applications today without taking some of the load off your database, and placing your common and intermediate data in the cache.

So which cache solution to use? NCache? Memcached? Redis? there seems to be so many solutions for on-premises environments. But what about the cloud? it seems that Windows Azure only has Windows Azure Caching, or does it?

The fact is you can use almost any caching solution in Windows Azure, you just need to know how to deploy it, and the meaning of running it in a cloud environment.

In this session, we will see how to use the built-in caching services offered by Windows Azure, as well as some other known caching solutions, such as Memcached and Couchbase. We will discuss the pros and cons of each solution and understand the caveats of hosting a cache in the cloud.

Why should you come to this session? where else would you get a feature comparison, performance benchmark, and specific deployment instructions for various caching solutions, which you can take back to your boss? Did I mention I’m also providing the code samples and deployment scripts?

IIS For Developers (75-minute session. Wednesday, 2:30PM)

This is my last session in the conference, but it’s also one of my favorites. I’ve been training developers and IT Pros on IIS for several years now, and I came to realize that many developers see IIS as a black box – you put your application in it, and it just works. Not many people actually know how IIS works, and how you can use it to better host and debug your Web applications.

In this session, we will go over the IIS Integrated pipeline to understand how it works, check some of the features of IIS , such as caching, URL rewrite, and application initialization, and go over the applications pool settings to better understand how those settings can help us cope with buggy web apps. We will also check the logging and tracing features of IIS, which can help us debug and analyze our applications.

So why should you come to this session? because purchasing a ticket to the conference, flying to Vegas, and sitting awake in my session after a big lunch, is a whole lot easier than asking your IT to teach you all those stuff about IIS .

If you haven’t registered to the conference yet, hurry up and register at http://www.devconnections.com/register

See you at the conference!

Hot off the shelf – MOC 20487B: Developing Windows Azure and Web Services

Ido Flatow — Fri, 23 Aug 2013 16:47:47 GMT

A couple of days ago I published my first post after an absence of 8 months, where I promised to tell you about the course I worked on for the past couple of months.

The 20487B course is an official Microsoft course, which myself and several other experts from Sela have been working on for the past 8 months.

As with the previous course I wrote for Microsoft (10263 – developing WCF services), this course also took a lot of time to develop because it involved creating an elaborated lab scenario, 14 course modules, and a whole lot of writing (688 pages in total, not including PowerPoint slides).

As the name implies, this course is about Web services and Windows Azure, but in fact, it covers a whole lot more. The purpose of this course is to teach developers how to create server-side distributed applications, using the Microsoft .NET stack. In this course, we cover the following topics:

Entity Framework – creating code-first models, working with DbContext, using LINQ to entities, Entity SQL, and more.
ASP.NET Web API – creating HTTP-based services and extending the Web API pipeline (message handlers, media type formatters, etc.). The modules also cover dependency injection, OData, and Web API security (basic stuff).
WCF – creating WCF services, hosting, message patterns, async operations, transactional services, and WCF security (the patterns, async, transactions, and security were originally part of the 20487A course, but in the new version, 20487B, we decided to make these as optional modules to free more time to other content).
Windows Azure

Hosting – this course mainly focuses on Web Sites and Cloud Services. Due to time limitations, we do not cover virtual machines.
Storage – using blobs, tables, and queues from .NET. The module also covers securing storage access with shared access signatures and policies.
Service bus – relays, queues, and topics. We might be adding material on notification hubs in the future.
Diagnostics – configuring and collecting diagnostics data from deployed cloud services.
ACS – securing Web API services and service bus using ACS.
Cache – deploying Windows Azure Caching solutions and using them from .NET applications.

Other stuff

Cloud computing – concepts and considerations.
Hosting and deployment - IIS, MSDeploy, GIT/TFS integration.
Scalability – architectural design and concepts, pitfalls, CDN, and traffic manager.

This course covers several topics which are still being updated (aside maybe for WCF which is only updated on newer version of the .NET Framework). Therefore, for the first time, Microsoft has decided that this course will be frequently updated to reflect changes to APIs, and new added features to the technologies (new Windows Azure services, EF6 changes such as async methods and connection resiliency, and new features of Web API, such as attribute-based routing).

Heads up to any MCT who is going to deliver this course:

The virtual machines we used for the course have the Windows Azure SDK 2.0 installed on them. Because of new SDKs and updated NuGet packages, labs may get broken, if newer versions of Windows Azure NuGet packages require newer versions of the SDK.

For such cases, we included in the labs the required steps for installing the old versions of NuGet packages, instead of the new ones. If students reports issues running the code, mainly exceptions about missing assemblies, you should instruct them to use the uninstall the current version and install the older version, which is specified in the lab notes. As part of supporting the course, we will be trying to identify NuGet package issues and inform MCTs about them.

Currently, I know of an issue with the Caching lab (module 12), because the new Windows Azure Caching NuGet package requires SDK 2.1. For this lab, please install version 2.0.0.0 of the package, as specified in the lab notes.

If you are an MCT and have any questions about the course, the content, or how to deliver parts of it, feel free to send me a message.

I’d also like to mention the other team members from Sela, who took part in authoring this course:

Authors – Yaniv Rodenski, Manu Cohen-Yashar, Ofir Makmal, Yuval Mazor, and Sasha Goldshtein.
Project Management team – Ishai Ram, Baruch Toledano, and Gal Tfilin.
Lab development, technical writers, testing, and IT - Israel Olcha, Roman Bryansker, Roee Moshe, Alex Lipov, Gil Blumberg, Morin Rodenski, Ernan Maisels, Lee Narkis, Meital Valenci, Daniel Sterman, Amith Vincent, Kavitha Ravipati, and Anuradha Sridhar.

Many thanks to the MSL team who was in charge of this course and to Steve Michelotti, our technical reviewer.

Also, congratulations for the Sela client team for releasing courses 20481, 20482, 20484, and 20485 (The Windows 8 Essentials and Advanced courses for C# and JavaScript).

Fixing IIS Advanced Logging Performance Counters Errors

Ido Flatow — Tue, 20 Aug 2013 16:43:59 GMT

Last time I posted on my blog was 10 months ago, wow! Time sure goes by fast when you have a new baby and a new course to write (I’ll blog about this later, the course, not the baby).

Enough with the chitchat, let’s get to business.

If you’ve ever used IIS, you’ve probably realized at some point that the IIS log files are useful to a point. You can’t log specific HTTP headers from the request/response, you can’t log machine parameters, such as performance counters, and you can’t filter the logs before they are written (for that we use log parser).

A couple of years ago, Microsoft released the Advanced Logging module, which can run in IIS 7/7.5/8 (haven’t tested on 8.5 yet, but part of it is already built-in to IIS 8.5). This new module adds many useful fields, real-time logging, and log filters.

One of the problem people stumbled upon when using this great module is, if you choose to log performance counters, you end up having two problems:

1. The counters data is not actually logged. If you open the log file, the columns appear, but without data.

2. If you open the Windows event logs, you’ll find errors for each configured performance counter. The errors are logged each time you recycle an application pool.

Note: event logs appear for each performance counter in the fields list, whether you choose to log it or not.

Most of the answers I found online for this issue (such as here) were to remove the performance counter fields from the list of fields, which basically will prevent you from logging performance counters. I didn’t really like these answers, as they didn’t actually resolve this issue, only worked around it.

After a short investigation, new evidence appeared that shed light on the problem – the issue with the performance counters appear only in web applications that use an application pool set to the ApplicationPoolIdentity identity. If the application pool uses Network/Local Service, there is no problem.

From here, the solution is simple:

1. Open the Local Users and Groups node in the Computer Management MMC.

2. Open the Performance Monitor Users group, and add the application pool identity you are using. For example, if your application pool is named DefaultAppPool, then add the user “iis apppool\defaultapppool”, without the quotes (“iis apppool” is a special prefix for application pool identities).

3. Reset your server for the changes to take affect.

After you reset the server and the application pool loads, you should start seeing the counter data in the log, and the errors in the Windows event logs will no longer appear.

Hope this helps someone out there.

Wrapping up SDP Nov. 2012

Ido Flatow — Thu, 29 Nov 2012 09:04:27 GMT

Wow, a conference that lasts 8 days, that a first. So here’s the gist of what I taught in 5 of these days:

What’s new in WCF 4.5
In this 1-hour session I covered some of the important new features of WCF 4.5, such as Intellisense for configuration, UDP and WebSockets bindings, and improved support for streaming and compression.
Debugging the Web with Fiddler
In this 1-day tutorial we saw how to use Fiddler to debug, test, and improve Web application. We saw how to work with the session list, use various inspectors, understand the meaning of statistics and timeline, manipulate messages with replays, breakpoints, and auto responder. We also saw how to create traffic with composer and how to create custom inspectors.
Building an App with Windows 8, Windows Azure and Visual Studio 2012 (with Michael Haberman)
The purpose of this 1-day tutorial was to show an end-to-end development of a distributed application that has a Windows 8 client-side, Entity Framework for database access, ASP.NET Wep API for server-side services, and hosting the entire server-side in Windows Azure (including SQL Database).
This tutorial day was not intended to be a deep dive into each technology, but rather show how the technologies work and fit together, and to discuss some best practices.
HTTP Fundamentals and ASP.NET Web API (with Yaniv Rodenski)
You wanted a deep-dive? you got it. This 1-day tutorial, which we taught twice during the conference, covers a whole lot of HTTP and its implementation with ASP.NET Web API. We talked about the HTTP requests and responses, verbs, URIs, and mapping it to Web API routing, controllers, and actions. We talked about Web API binders, action filters, and message handlers. We talked about HTTP concepts, such as caching, streaming, compression, and persistent connections. We talked about security, IIS hosting, the HTTP.SYS listener, WebSockets, and about so much more.

All the slide decks and demo code from these days is available online at http://sdrv.ms/WhqCfT

See you in the next SDP.

BUILD 2012 – Day 4 Overview

Ido Flatow — Sun, 04 Nov 2012 03:39:33 GMT

First session of Day 4 was about advanced cloud service development. I came in a bit late so I missed the introduction, but the part about diagnostics and IIS 8 was nice – IIS 8 and Windows Server 2012 offer new stuff such as .NET 4.5 on web/worker roles, SignalR, and Websocket support. CDN and traffic manager cover was shallow, but the Service Bus part was nice where he showed service bus topics.

Session number 2 was about Windows Azure Storage. There are a couple of new things coming to Azure Storage, and new stuff that will be available in a couple of weeks/months (see images).

Session number 3 was about Windows Azure Service Bus. When the session began it seemed like an introduction session so I bailed. I understand that at the end of the session he mentioned that Service Bus now supports AMQP (advanced message queue protocol).

Last session of the day/conference was about ASP.NET and VS 2012 by Scott Hanselman and John Galloway. Great session with great interaction between Scott and John, really worth watching. The new stuff which were introduced were the new features of ASP.NET which is going to be released soon – new Web API features, new templates for single-page web apps, SignalR as part of the Microsoft stack for ASP.NET, VS 2012 improvements, and on.

So that’s it for Build. Continuing to the Windows Azure Insiders post-con where I learning new stuff that I can’t talk about . You’ll find out about it soon…

BUILD 2012 – Day 3 Overview

Ido Flatow — Fri, 02 Nov 2012 05:10:52 GMT

Day 3 began with a great ~~keynote~~ session by Scott Hanselman, one hour that recapped my entire webdev history (being doing this stuff for the past 15 years).

The bottom line of the session was – remember that you also have a very powerful machine on your desk (or legs if it’s a laptop), so don’t just throw everything on the server, try to also use javascript to do stuff.

After Scott’s session I stayed in the hall for the TypeScript session. Writing JavaScript with JavaScript – well, as long as it doesn’t like feel I’m writing JavaScript, it’s great (I don’t like JavaScript that much). I’m having a hard time finding thinking of a similar concept from previous technologies where you created a new language to hide syntax difficulties of another language (or in this case, use the same language for both), but the idea is nice, I’ll give it a couple of months to see if it catches up. Anyway, using TypeScript to create JavaScript code for Node.js is nice.

(Sorry, no photo)

I then moved on to a Windows Azure Internals session by Mark Russinovich. It’s the same session he had in TechEd 2012, but it was nice hearing it again. For server guys, looking at the internal of Windows Azure is what looking into the internals of Windows 8 is for client devs. In the session he also covered how they handled the famous 29-Feb (leap year) bug they had this year (note to self: don’t do nextyear = date.Year + 1 – it doesn’t work with leap years, duh!).

This was actually my last session for the day, as I had lots of work piling up which had to be handled.

See you in tomorrows post about day 4.

BUILD 2012 – Day 2 Overview

Ido Flatow — Thu, 01 Nov 2012 10:13:05 GMT

So day 2 started with a keynote that had “Windows Azure” written all over the stage, so that was promising (see overview of day 1).

By the way, if you’ll compare the stage to yesterday’s keynote you’ll see the stage is empty – that is because all the demos are in the cloud

Some of the stuff shown in the keynote:

Mobile Services.
this feature was rolled out in August, but the demo was very good and managed to show the highlights of Mobile Services in a couple of minutes. Really great demo, I recommend you watch it.
Web API and SignalR.
Most of these stuff are already known for a couple of months, but the release of SignalR in ASP.NET 4.5 is a bit new.
Media Services.
A not so used feature of Windows Azure (at least by me), but sounds cool for people wanting to publish media through Windows Azure.
TFS.
Team Foundation Services (not to be confused with the other TFS – Team Foundation Server) has been released. If you have a team of under 5 people the service is free, for bigger groups, it is currently free, but next year prices will be announced (free for MSDN subscribers).
Hadoop and HDInsight.
There is a new SDK and HIVE is also queryable now with LINQ.

Some other announcements:

Caching – The Windows Azure Caching is out of preview and is now GA (general availability)
SDK 1.8 – The October SDK is out with some new stuff
.NET 4.5 in Cloud Services – Last week it was announced that Web Sites support .NET 4.5, and now Cloud Services (Worker/Web roles) also support it.

After this very long but cool keynote I went on to pick my sessions. Had to skip the first set of sessions because they were mostly introduction-level. After lunch I went on to see Mark Russinovich’s session about IaaS in Windows Azure (Virtual Machines and Virtual Networks). I’m familiar with some of this stuff, but hearing Mark is always much fun, and you also get to see some of the inner tools that are used by the Windows Azure team.

My next session was the Advanced IaaS session. It was a lot more technical than the introductory session (duh). Using PowerShell and other Command-Line tools to control Virtual Machines in Azure.

Sorry for the lousy picture, I sat in the back. Also for the odd slide, I missed the photo-op of the summary slide.

My last session for the day was about building highly available solutions in Windows Azure (part II). The session was nice, showing some tips for properly using retry policies for SQL Databases and Windows Azure Caching. There was also some tips about diagnostics in Windows Azure Web apps, nice content.

Waiting for day 3 for more Windows Azure sessions, and for our Windows Azure Insiders Post-Conference.

BUILD 2012 – Day 1 Overview

Ido Flatow — Thu, 01 Nov 2012 04:50:00 GMT

Ok, first, just in case you aren’t familiar with my work – I’m a server/web/cloud guy, not a client guy, so all the hype about Windows 8 and Phone 8 sounds to me like “bla bla bla”. I’m into servers and Windows Azure, so day 2 and on is more to my like than Day 1.

So day 1 began with the keynote where Steve Ballmer did his “shopping channel” appearance, showing the various hardware running Windows 8.

BTW, in the first photo, on the left, you can notice an 82” surface .

Then the keynote continued to showing off the new Windows Phone 8, and the announcement that the SDK has been released, yey (as mentioned, I’m not a client guy).

The rest of the day was mostly Windows 8 / Phone 8 sessions, so I looked for the one session that was about .NET stuff, and found the Entity Framework session which was cool, since at the end of it we saw some of the new features of Entity Framework 6 which was released today in Alpha.

I really like some of the new features, especially the conventions that will make life easier for developers that have to deal with DBAs that are strict about database conventions.

The rest of the day was spent on talking to people about Windows Azure, and checking out our (Sasha Goldstein, Dima Zurbalev, and yours truly) new “Pro .NET Performance” book in the Microsoft Store (4th from the right):

Oh, and we also got some SWAG – a new Windows 8 surface and a Windows 8 phone.

Day 2 and on is server and Azure, so good stuff to come…

Two months speaking spree

Ido Flatow — Fri, 05 Oct 2012 22:03:46 GMT

If you’ve been checking my blog in the last couple of weeks, you might have noticed I haven’t been posting much. In the past two months I have been traveling around the world, speaking in conferences and local user groups.

So to sum up this intensive, fun times, here’s a list of all conferences I visited and links to all the material I showed.

What’s new in WCF 4.5
Building scalable, low-latency web apps with Windows Azure
Embracing HTTP with the ASP.NET Web API

You can download the slides and code samples from here

Debugging the web with Fiddler

Building scalable, low-latency web apps with Windows Azure
Debugging the web with Fiddler

You can download the slides and code samples from here

Embracing HTTP with the ASP.NET Web API

Building scalable, low-latency web apps with Windows Azure

You can download the slides and code samples from here

Building scalable, low-latency web apps with Windows Azure
The new face of ASP.NET: ASP.NET MVC, Razor, and jQuery
Embracing HTTP with the ASP.NET Web API

You can download the slides and code samples from here

As for future conferences, I’m going to have a couple of sessions and tutorials in the SDP (Sela Developer Practice) conference which will be in November in Israel. I will have a 1-hour session about the new features of WCF 4.5, and the following three tutorial days:

Debugging the web with Fiddler
Building an App with Windows Phone, Windows Azure, and Visual Studio 2012 (this tutorial will be with Michael Haberman and Yaniv Rodesnki)
HTTP fundamentals and ASP.NET Web API (this tutorial will be with Yaniv Rodesnki)

So to sum up this bunch of conferences and the previous one:

1 year, 3 continents, 7 countries, 9 conferences, 24 sessions.

That’s it for 2012 conferences.

Slides and demo from my Azure UG session

Ido Flatow — Thu, 26 Jul 2012 21:22:30 GMT

Early this week I had a session about building scalable, low-latency, secured web applications with Windows Azure.

During the session, and despite all the network problems we had, I showed how to migrate an ASP.NET 4 MVC app to Windows Azure and incorporate the following features:

Cloud services (compute)
Storage
CDNs
Full IIS support
Diagnostics
ACS and claim-based identities with WIF
SQL Azure
Caching worker roles

The demo code and the few slides I shown are available online at: http://sdrv.ms/OmSA2n

I’m going to have this session three more times during the next couple of months in the US, Germany, and Denmark, so if you happen to attend one of these places, come and say hi.

Also, if anyone wish to have me speak at their local user group while I’m attending these conferences, let me know via email or Twitter (@IdoFlatow).

Fixing issues with IIS Express 8 after installing Windows Azure SDK 1.7

Ido Flatow — Sun, 24 Jun 2012 22:35:21 GMT

If you are having problems using IIS Express 8 to host local Azure deployments after installing the Windows Azure SDK 1.7, you should probably continue reading this…

One of the new features of the Azure SDK 1.7 is the support for running local emulator with IIS Express 8 instead of the full IIS. This is supported for both Windows 7 and Windows 8.

At first when I tried this feature it simply didn’t wok. I previously had IIS Express 7.5 on my machine, and after installing the new SDK, I created a new web role, and when trying to run it locally, IIS Express did not fire up, and the browser opened showing it is unable to locate the requested address.

I then uninstalled the SDK, followed by uninstalling IIS Express. After making sure I don’t have any IIS Express “leftovers” in my machine, I reinstalled the Azure 1.7 SDK, making sure it also installed the new version of IIS Express.

Next, I opened the previously created project, and this time when I tried to run it, the following message appeared:

“The Windows Azure Emulator could not start the web server. The properties for this project specify that it should run on IIS Express, but no compatible version of IIS Express was found. To run this project, either install IIS Express 8 or higher, or change the ‘Use web server’ property for this project to ‘Local IIS web server’. See output window for more information.”

Since IIS Express 8 was successfully installed and it did work (VS 2010 SP1 was able to run web sites on it), it was time for the big guns – using reflector to find out what csrun.exe does. It seems that one of the first things csrun does is to create a COM object called Microsoft.IIS.VersionManager to check which version of IIS is installed on the machine. After opening the registry and finding the key, I discovered that I don’t have permission to read the key. Eureka!

Following this forum thread, I was able to add permissions to the key. After setting the permissions, I returned to Visual Studio, and this time I had no problem getting the emulator to use IIS Express 8 to host my web site. Problem solved!

Note: If you need to look for the registry key, it is located under HKEY_LOCAL_MACHINE\Software\Microsoft\Classes\Microsoft.IIS.VersionManager (make sure you also check permission on the second key, Microsoft.IIS.VersionManager.1)

Until the next bug…

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

Ido Flatow — Fri, 23 Mar 2012 04: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 20:57:00 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 18: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.