Advanced ASP.NET Web API Webcast Offline Recording (In Turkish) is Available

Advanced ASP.NET Web API Webcast Offline Recording (In Turkish) is Available
2012-11-07 09:27
Tugberk Ugurlu

A week ago, we tried to organize a webcast on ASP.NET Web API but there were a few problems with the network connection. It didn’t go that smoothly as you can imagine but I have provided the slides and the full source code of the webcast content earlier. During the last weekend, I recorded an offline video for the same topic (In Turkish) and it’s now available on NedirTV: Ileri Düzey ASP.NET Web API

You can also watch it on Vimeo:

İleri Düzey ASP.NET Web API from Tugberk Ugurlu on Vimeo.

Enjoy Smile


Why am I writing this in English if the content of this recording is in Turkish? Well, I don’t have a Turkish blog yet and I really don’t want to mix languages inside the current one Confused smile I plan on opening up a Turkish blog, too. Not sure when, though. So, stay tuned Surprised smile

Advanced ASP.NET Web API Webcast Slide and Codes

The slide and the full source code of the Advanced ASP.NET Web API webcast (Turkish) is available.
2012-11-02 07:07
Tugberk Ugurlu

The full source code of the Advanced ASP.NET Web API webcast (Turkish) is now available on GitHub:

The slide of the webcast is also available is also reachable from the following link:

ASP.NET SignalR Alpha 1.0.0 is Now Available!

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!
2012-10-31 23:31
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

Working with IIS Express Self-signed Certificate, ASP.NET Web API and HttpClient

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.
2012-10-23 19:34
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

Newsflash! ASP.NET Web API does not Sit on Top of ASP.NET MVC! In Fact, It does not Sit on Top of Anything

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!
2012-10-20 08:57
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