Filtered by Month (10) and Year (2012)
Couple of hours ago, @DamianEdwards has announced that ASP.NET SignalR Alpha 1.0.0 release is now publicly available! Even better! SignalR has just shipped with ASP.NET Fall 2012 Update!
@ 10-31-2012
by Tugberk Ugurlu

Couple of hours ago, @DamianEdwards has announced that ASP.NET SignalR Alpha 1.0.0 release is now publicly available.

You can now get the SignalR into your web project through NuGet with the following command:

PM> Install-Package Microsoft.AspNet.SignalR -Pre

Even better! SignalR has just shipped right out of the box with ASP.NET Fall 2012 Update! I tried to have a quick view of what has added and changed. In this post, I will share just a few of them.

When you install the package, you will get the most of the usual stuff.


There is one more thing that I haven’t see before (not sure if this has been there with 0.5.3 release). The project is no more registering itself invisibly and RegisterHubs class accomplishes for us.


The one other thing that I fell in love with is to be able to return a Task or Task<T> from the hub method! This is a killer feature! Again, I am not sure if this was on 0.5.3 release but I am glad this is now there!


And here it is! We have been all waiting for this one Smile We now have an AuthorizeAttribute Smile


This attribute implements IAuthorizeHubConnection and IAuthorizeHubMethodInvocation interfaces to be recognized as an authorization attribute. So, this means that you can provide your own! If you are familiar with ASP.NET MVC or ASP.NET Web API, the concept here is the same. However, the interface methods return bool to signal the caller if the call is authorized or not. I would really love to be able to return Task<bool> here or have a similar filter model as ASP.NET Web API. Keep in mind that these are authorization points and they are not meant to be used to perform authantication. SignalR completely leaves the authantication to the underlying hosting layer.

I’m sure there are other features but it is 03:24 AM here and my eyes are closing Smile So, it is enough for now. Big thanks and kudos to @davidfowl and @DamianEdwards for the Alpha release and for bringing this such a great framework to life.

If I were you, I would go to SignalR Github repository and start exploring the samples. They are awesome and cover the new stuff. Also, @DamianEdwards and @davidfowl has a //Build talk tomorrow which will be streamed live: Don’t miss that one!

More Information

We will see how to smoothly work with IIS Express Self-signed Certificate, ASP.NET Web API and HttpClient by placing the self-signed certificate in the Trusted Root CA store.
@ 10-23-2012
by Tugberk Ugurlu

If you would like to only support HTTPS with your ASP.NET Web API application, you might also want expose your application through HTTPS during the development time. This is not a big problem if you are heavily integration-testing your Web API as you can pass anything you want as a host name but if you are building your HTTP API wrapper simultaneously, you want to sometimes do manual testing to see if it’s actually working. There are sevaral ways to sort this problem out and one of them is provided directly by Visual Studio. Visual Studio allows us to create HTTPS bindings to use with IIS Express during development time. Let’s see how that works.

Note: I am assuming everybody understands that I am talking about ASP.NET Web API web host scenario with ASP.NET here. This blog post is not about self-host scenarios.

First of all, I created an empty web application through visual studio. Then, I added one of my NuGet packages: WebAPIDoodle.Bootstrap.Sample.Complex. This package will get you all ASP.NET Web API stuff and a working sample with all CRUD operations.

I also created a message handler which is going to ensure that our API is only going to be exposed over HTTPS.

public class RequireHttpsMessageHandler : DelegatingHandler {

    protected override Task<HttpResponseMessage> SendAsync(
        HttpRequestMessage request, 
        CancellationToken cancellationToken) {

        if (request.RequestUri.Scheme != Uri.UriSchemeHttps) {

            var forbiddenResponse = 

            forbiddenResponse.ReasonPhrase = "SSL Required";
            return Task.FromResult<HttpResponseMessage>(forbiddenResponse);

        return base.SendAsync(request, cancellationToken);

Then, I registered this message handler as you can see below:

protected void Application_Start(object sender, EventArgs e) {

    var config = GlobalConfiguration.Configuration;


    config.MessageHandlers.Add(new RequireHttpsMessageHandler());

To configure the HTTPS endpoint with IIS Express, I simply need to click on the web application project and press F4. This will bring up the project properties and there will be a option there called "SSL Enabled".


By default, this is set to False as you can see. If we change this and set it to True, Visual Studio will create the necessary binding for our application by assigning a new port number and attaching the pre-generated self-signed certificate for that endpoint.


Now, when we open up a browser and navigate to that HTTPS endpoint, we should face a scary looking error:


As our certificate is a self-signed certificate, the browser doesn’t trust that and gives this error. This error is not a blocking issue for us and we can just click the Proceed anyway button to suppress this error and everything will be work just fine.

Let’s close the browser and create a very simple and naïve .NET console client for our API as below:

class Program {

    static void Main(string[] args) {


    public static async Task<string> GetStringAsync() {

        using (HttpClient client = new HttpClient()) {

            return await client

As I said, it is insanely simple Smile but will serve for our demo purposes. If we run this console application along with our Web API application, we should see an exception thrown as below:


This time the HttpClient is nagging at us because it didn’t trust the server certificate. If we open up the browser again and take a look at the certificate, we will see that it is also complaining that this self-signed certificate is not in the Trusted Root CA store.


One way to get rid of this problem is to place this self-signed certificate in the Trusted Root CA store and the error will go away. Let’s first open up a PowerShell Command window and see where this self-signed certificate lives.


As we now know where the certificate is, we can grab this certificate and place it in the Trusted Root CA store. There are several ways of doing this but I love PowerShell, so I am going to do this with PowerShell, too. To be able to perform the below operations, we need to open up an elevated PowerShell Command Prompt.


Let’s explain what we did above:

  • We retrieved our self-signed certificate and stuck it into a variable.
  • Then, we retrieved the Trusted Root CA store and stuck that into a variable, too.
  • Lastly, we opened up the store with Read and Write access and added the certificate there. As a final step, we closed the store.

After this change, if we take a look at the Trusted Root CA store, we will see our certificate there:


If we now run our console client application, we should see it working smoothly.


I hope this will help you as much as it helped me Smile

One of the common misconceptions about ASP.NET Web API is that it is being built on top of ASP.NET MVC. Today, I am going to break it!
@ 10-20-2012
by Tugberk Ugurlu

One of the common misconceptions about ASP.NET Web API is that it is being built on top of ASP.NET MVC (particularly ASP.NET MVC 4). In my opinion, the distribution of ASP.NET Web API along with ASP.NET MVC installer has the biggest effect on this misconception. The other effect might be that the programming models in both frameworks are very similar. In fact, you will find some classes with the same name in both frameworks.

Here is the Deal

Sorry folks but I am going to break the news for you: ASP.NET Web API doesn’t sit on top of ASP.NET MVC. To be more accurate, ASP.NET Web API doesn’t sit on top of anything other than .NET. You can make it sit pretty much on top of wherever the hell you want for it to sit. This is the concept which makes it so darn easy to self-host ASP.NET Web API. The team made this awesome framework sit on top of ASP.NET and WCF by providing two hosting options right out of the box.

Let's make something more clrear because I don't wanna give the wrong impression here. ASP.NET MVC and ASP.NET Web API runs perfectly side by side. It's just that ASP.NET Web API has nothing to do with ASP.NET MVC.

Ok, you wouldn't want to believe a random dude on the internet, would you? Let’s dig a little deeper to see whether I am fabricating here or not.

Prove it!

Let’s open up the ASP.NET Web Stack source code in Visual studio and have a look at the reference list of System.Web.Http project:

10-20-2012 2-24-47 PM

System.Web.Http.dll is the core assembly which holds the logic and everything related to ASP.NET Web API. When you look at the References tab in the above picture, can you see any System.Web.Mvc reference there? No (unless you are hallucinating)! Actually, take a closer look again. Can you now even see any System.Web reference there? No (unless you are hallucinating)! This is because the fact that ASP.NET Web API core infrastructure has been decoupled from the hosting layer.

The below picture shows the assembly references of the ASP.NET hosting project for Web API:

10-20-2012 2-07-18 PM

You can see that System.Web is now referenced here, but can you see any System.Web.Mvc reference here? No (unless you are hallucinating)! So, I am very curious here about where they have gotten the idea that ASP.NET Web API runs on top of ASP.NET MVC because it simply does not!

Let’s now dig a little deeper to see how ASP.NET hosting has been implemented and this will give us a better understanding. ASP.NET Web API plays by the rules and registers itself into the ASP.NET pipeline just like ASP.NET MVC does: with IRouteHandler and IHttpHandler (actually IHttpAsyncHandler) implementations:

10-20-2012 2-13-07 PM

In my personal opinion, the ASP.NET Web API has been designed so beautifully. All the stuff that the hosting layer needs to do is to construct a new HttpConfiguration object and pass that configuration on to HttpServer instance and BOM! You can then invoke that HttpServer instance with HttpMessageInvoker (or anything else which will do the job) and you are now inside the ASP.NET Web API pipeline. This is what HttpControllerHandler is actually doing in an ASP.NET hosting scenario. It gets the HttpContextBase and converts it into an HttpRequestMessage instance. Later, it uses that newly created HttpRequestMessage to invoke the SendAsync method of the HttpMessageInvoker.

This type of design also allows us to write beautiful and easy integration tests against our ASP.NET Web API application. You can find more information about ASP.NET Web API integration testing on Filip’s blog post.

I am now hoping that this will give you a better idea how ASP.NET Web API has been structured and where it really sits on Smile

Two days ago, I blogged about the availability of the Pro ASP.NET Web API Book through Apress Alpha Program. Today, the Pro ASP.NET Web API book is now available on Amazon for pre-order
@ 10-15-2012
by Tugberk Ugurlu

Two days ago, I blogged about the availability of the Pro ASP.NET Web API Book through Apress Alpha Program. It was a very valuable blog post for me because this is my first book. Today, I can tell you that you can pre-order Pro ASP.NET Web API book on Amazon and it will be delivered to you when it is available.

In this post, I would like to also give you some information about the book that we are writing. Pro ASP.NET Web API will guide you how to build flexible, extensible web services that run seamlessly on a range of operating systems and devices, from desktops to tablets to smart phones.

We also plan the book to consist of mainly three parts. In Part I, you'll get up to speed on Web API's modern HTTP programming model, asynchronous programming in .NET framework and basic HTTP information. Part II takes you through building a real application so you can see straight away how to put this new technology into practice. The second half of the book features dedicated chapters on topics like routing, controllers, validation and tracing, and we will have chapters on performance, security and an all-important look at unit testing to help you prepare your application for the real world.

ASP.NET Web API makes HTTP a first-class citizen of .NET. With Pro ASP.NET Web API, you will learn how to build HTTP-based web services for your company or business, expose your data to the world across different formats and devices and gain the best possible global reach for your application.

We have still a few chapters to complete but we work hard to get it done as soon as possible. I hope you will enjoy the book Smile

I am proud to announce that the Pro ASP.NET Web API book is available through Apress Alpha Program and you can get access to the early bits and completed chapters now.
@ 10-13-2012
by Tugberk Ugurlu

Since April 2012, me and Alexander Zeitler have been working on a book for ASP.NET Web API which is a framework that makes it easy to build HTTP services that reach a broad range of clients, including browsers and mobile devices. Today, all of our efforts have come to fruition and I am proud to announce that the Pro ASP.NET Web API book is available through Apress Alpha Program.

I believe that we are producing an incredibly useful resource which any developer, who wants to leverage the ASP.NET Web API framework, needs under her/his hand. We aimed to avoid explaining and extracting implementation details of the framework as much as possible. Instead, we try to give more examples and use-cases for each component of the framework. There is also going to be a sample application walkthrough.

If you don’t know what The Apress Alpha Program is, here is a little quote from Apress web site:

The Alpha Book Program

Want to get an early look at our titles? Try an Alpha Book! An Alpha Book is a pre-release, still-in-development version of an Apress title. When you purchase an Alpha Book, you get the opportunity to review its content as it advances through the production process. Alpha Book files are updated on a regular basis in your account as new material is completed, all the way through final publication.

Lots of valuable people put her/his effort on this book, especially the acquisitions editor Gwenan Spearing, coordinating editor Anamika Panchoo, development editor Chris Nelson, technical reviewer Robert Swafford, copy editor Tom McCarthy. I would like to thank all of them and the others who made it possible to produce this high quality resource.

We have still a few chapters to complete but we would love to get feedback for the currently available pieces. Go and participate the alpha program and get access to the early bits and completed chapters of the Pro ASP.NET Web API book. Don’t hesitate to reach out to me in any way to give feedback :)

Hi 🙋🏻‍♂️ I'm Tugberk Ugurlu.
Coder 👨🏻‍💻, Speaker 🗣, Author 📚, Microsoft MVP 🕸, Blogger 💻, Software Engineering at Deliveroo 🍕🍜🌯, F1 fan 🏎🚀, Loves travelling 🛫🛬
Lives in Cambridge, UK 🏡