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

ASP(.)NET SignalR 1.0.0 Alpha 1 now live on #nuget! nuget.org/packages/micro…

— Damian Edwards (@DamianEdwards) October 31, 2012

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

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 We now have an AuthorizeAttribute

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 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: http://channel9.msdn.com/Events/Build/2012/3-034 Don’t miss that one!

More Information

• Blog: Microsoft ASP.NET SignalR by David Fowler
• SignalR on Github
• SignalR Website

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 = 
                request.CreateResponse(HttpStatusCode.Forbidden);

            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) {

        Console.WriteLine(GetStringAsync().Result);
        Console.ReadLine();
    }

    public static async Task<string> GetStringAsync() {

        using (HttpClient client = new HttpClient()) {

            return await client
               .GetStringAsync("https://localhost:44304/api/cars");
        }
    }
}

As I said, it is insanely simple 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

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:

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:

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:

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

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