Filtered by Tag (hosting)
OWIN and Katana is best way to build web server indipendent web applications in .NET ecosystem and this post will help you a bit on getting started.
@ 05-04-2013
by Tugberk Ugurlu

As usual, I tweeted about my excitement which finally led me to this blog post:

OWIN and Katana project is the effort moving towards that direction and even through it's at its early stages, the adoption is promising. Katana is a flexible set of components for building and hosting OWIN-based web applications. This is the definition that I pulled from its Codeplex site. The stack includes several so-called OWIN middlewares, server and host implementations which work with OWIN-based web applications. You can literally get your application going within no time without needing any installations on the machine other than .NET itself. The other benefit is that your application is not tied to one web server; you can choose any of the web server and host implementations at any time without needing to recompile your project's code.

To get started with Katana today, the best way is to jump to your Visual Studio and navigate to Tools > Library Package Manager > Package Manager Settings. From there, navigate to Package Sources and add the following sources:

Now, we should be able to see those sources through PMC (Package Manager Console):


We performed these actions because latest bits of the Katana and OWIN Hosting project are pushed to MyGet and those packages are what you want to work with for now. As you can guess, those packages are not stable and not meant to be for production use but good for demonstration cases :) Let's start writing some code and see the beauty.

I started by creating an empty C# Class Library project. Before moving forward, I would like to take a step back and see what packages I have. I selected the MyGet Owin as the current package source and executed the following command: Get-Package -ListAvailable -pre


These packages are coming from the OWIN Hosting project and I encourage you to check the source code out. Let's do the same for the MyGet Katana source:


We got more packages this time and these packages are coming from the Katana project which is hosted on Codeplex. These packages consist of OWIN middlewares, host and server implementations which we will have a chance to use some of them now.

Let's start installing a host implementation: Microsoft.Owin.Host.HttpListener pre-release package. Now, change the current package source selection to MyGet OWIN and install Owin.Extensions package to be able to get the necessary bits and pieces to complete our demo.

The Owin.Extensions package will bring down another package named Owin and that Owin package is the only necessary package to have actually. The others are just there to help us but as you can understand, there is no assembly hell involved when working with OWIN. In fact, the Owin.dll only contains one interface which is IAppBuilder. You may wonder how this thing even works then. The answer is simple actually: by convention and discoverability on pure .NET types. To get a more in depth answer on that question, check out Louis DeJardin's awesome talk on OWIN.

What we need to do now is have a class called Startup and that class will have a method called Configuration which takes an IAppBuilder implementation as a parameter.

public partial class Startup {

    public void Configuration(IAppBuilder app) {

        app.UseHandler(async (request, response) => {

            response.ContentType = "text/html";
            await response.WriteAsync("OWIN Hello World!!");

For the demonstration purposes, I used the UseHandler extension method to handle the requests and return the responses. In our case above, all paths will return the same response which is kind of silly but OK for demonstration purposes. To run this application, we need to some sort of a glue which needs to tie our Startup class with the host implementation that we have brought down: Microsoft.Owin.Host.HttpListener. That glue is the OwinHost.exe which we can install from the MyGet Katana NuGet feed.


OwinHost.exe is going to prepare the settings to host the application and give them to the hosting implementation. Then, it will get out of the way. To make it run, execute the OwinHost.exe without any arguments under the root of your project and you should see screen as below:


We got this unfriendly error message because the OwinHost.exe was unable to locate our assemblies as it looks under the bin directory but our project outputs the compiled assemblies under bin\Debug or bin\Release; depending on the configuration. Change the output directory to bin through the Properties menu, rebuild the solution and run the OwinHost.exe again. This time there should be no error and if we navigate to localhost:5000 (as 5000 is the default port), we should see that the response that we have prepared:


Cool! You may wonder how it knows to which host implementation to use. The default behavior is the auto-detect but we can explicitly specify the server type as well (however, it's kind of confusing how to do it today):


OwinHost.exe is great but as you can guess, it's not our only option. Thanks to Katana project, we can easily host our application on our own process. This option is particularly useful if you would like to deploy your application as a Windows Service or host your application on Windows Azure Worker Role. To demonstrate this option, I created a console application and referenced our assembly. Then, I installed Microsoft.Owin.Hosting package to be able to host it easily. Here is the code to do that:

class Program {

    static void Main(string[] args) {

        using (IDisposable server = WebApp.Start<Startup>()) {


When I run the console application now, I can navigate to localhost:5000 again and see my response:


I plan on writing a few more posts on OWIN-based applications but for now, that's all I can give away :) The code I demoed here is available on GitHub as well: but run the Build.cmd file before starting.

Note: Earlier today, I was planning to play with ASP.NET Web API's official OWIN host implementation (which will come out in vNext) and writing a blog post on that. The playing part went well but Flip W. was again a Sergeant Buzzkill :s



In this blog post, we will see how to run ASP.NET MVC application under IIS 6.0 and IIS 7.0 classic mode with some configurations on IIS and Global.asax file...
@ 02-26-2011
by Tugberk Ugurlu

Highway sign

I wrote a blog post on Deployment of ASP.Net MVC 3 RC 2 Application on a Shared Hosting Environment Without Begging The Hosting Company couple of months ago. The solution was working for most case scenarios if the server is configured properly for ASP.NET Routing. Other working case I have seen was the applications which are running under IIS 7.0 integrated mode. Under IIS 7.0 integrated mode, no special configuration necessary to use ASP.NET Routing.

As we know, one of the most beautiful parts of ASP.NET MVC framework is Routing. We have nice, clean, extensionless URLs thanks to routing and this is becoming an issue under IIS 6.0 and IIS 7.0 classic mode.

When we typing the path of a web site page inside the address bar of our web browser, we are making a request against server. If our web application is running under any version of IIS, the request hits ASP.NET framework on certain conditions. Especially, Older versions of IIS only map certain requests to the ASP.NET framework. If the extension of the web request is aspx, ashx, axd or any other extensions which is specific for ASP.NET framework are being mapped to ASP.NET framework. So, in a MVC application the requests are not being mapped to ASP.NET framework. 

(You will be getting this 404 exception when you hit the extensionless URL of your application)

No, do not throw away your precious, new born ASP.NET MVC application which you have created working along with Nuget PMC (which is perfect), EFCodeFirst and any other cool newbie stuff.  There are optional solutions for this problem and they are not like hard things to implement.

Although, if you have a Windows Server 2003 and thinking about going up to IIS 7.0 integrated or classic mode, stop right there my friend ! Because, IIS 7.0 is not compatible with Windows Server 2003. So you are stuck with IIS 6.0 for now and keep reading for the solution Smile

The solutions are optional as indicated. They depend on what kind of powers you have over your server. Here is the list of solution you might be interested;

Option 1 : I am the guy with the full control power over my server and I want to keep extensionless URLs

If you have full access over your server, you could create so called Wildcard Script Map so that you can use the default ASP.NET MVC route table with IIS 7.0 (in classic mode) or IIS 6.0. This Wildcard Script Map will map all requests to the web server to the ASP.NET framework.

I have no experience with this option, though. I had a problem like this within this week, I have solved it with the following option and didn’t want to use this one even if I have full control over my server. I am not a server pro, so I won’t be making any comments on how this will effect the requests flow made against your server. I just thought that “man, every single request which made against my server will be mapped to ASP.NET framework. This could effect the speed of the delivery process.” and that how I skipped this option.

And, bad news guys Sarcastic smile Microsoft, also, indicated the following line of sentence one of their web site;

“Be aware that this option causes IIS to intercept every request made against the web server. This includes requests for images, classic ASP pages, and HTML pages. Therefore, enabling a wildcard script map to ASP.NET does have performance implications.”

To implement this feature, you need to follow some steps and here is the text I grabbed from ;



Here's how you enable a wildcard script map for IIS 7.0 (classic mode):

  1. Select your application in the Connections window
  2. Make sure that the Features view is selected
  3. Double-click the Handler Mappings button
  4. Click the Add Wildcard Script Map link
  5. Enter the path to the aspnet_isapi.dll file (You can copy this path from the PageHandlerFactory script map)
  6. Enter the name MVC Click the OK button





Follow these steps to create a wildcard script map with IIS 6.0:

  1. Right-click a website and select Properties
  2. Select the Home Directory tab
  3. Click the Configuration button
  4. Select the Mappings tab
  5. Click the Insert button
  6. Paste the path to the aspnet_isapi.dll into the Executable field (you can copy this path from the script map for .aspx files)
  7. Uncheck the checkbox labeled Verify that file exists
  8. Click the OK button


Option 2 : I am the guy who has the full control power over my server, cares about performance and not care about URLs

This option is the one of the other option I do not like very much but maybe you will Smile So here is the deal;

We will simply add Extensions to the Route Table so that older versions of IIS can pass requests to the ASP.NET framework. This option requires changes inside Global.asax file of you application and some addition work on IIS for modifying the Default route so that it includes a file extension that is mapped to the ASP.NET framework.

Let’s see the RegisterRoutes method inside your Global.asax file;

        public static void RegisterRoutes(RouteCollection routes)

                "Default",                                              // Route name
                "{controller}/{action}/{id}",                           // URL with parameters
                new { controller = "Home", action = "Index", id = "" }  // Parameter defaults


As you see here on line 7, we are aiming to get URLs without extension. Let’s see what it needs to be look like after we change it in order to implement this option;

        public static void RegisterRoutes(RouteCollection routes)

                new { action = "Index", id = "" }

              new { controller = "Home", action = "Index", id = "" }


Here, we are assigning .mvc extension for every URL for controller name.

I want to warn you about your links inside your views. If you created them by hard coding, now you are officially screwed my friend. Because, you either have to change all of them by hand or need to implement option 1 in order to keep them unbreakable. If you used ActionLink or RouteLink kind of way, then your are good to go. Changes will be handled by MVC Framework for you.

Therefore, to get ASP.NET Routing to work, we must modify the Default route so that it includes a file extension that is mapped to the ASP.NET framework.

This is done using a script named registermvc.wsf. It was included with the ASP.NET MVC 1 release in C:\Program Files\Microsoft ASP.NET\ASP.NET MVC 1.0\Scripts, but as of ASP.NET 2 this script has been moved to the ASP.NET Futures, available at

Executing this script registers a new .mvc extension with IIS. After you register the .mvc extension, you can modify your routes in the Global.asax file so that the routes use the .mvc extension.

After this implementation, your URLs will look like this;




Option 3 : I am the guy who has no control power over my server, not care about URLs (If you care, it does not matter. You have no choice)

This option is the easiest way of make your application up and running within minutes depending on your application structure. Only you need to do here is; making some changes inside your Global.asax file, recompiling your application and publishing it into your server. That’s all. Let’s see how our new RegisterRoutes method inside Global.asax file needs to be look like;

        public static void RegisterRoutes(RouteCollection routes)

                new { action = "Index", id = "" }

              new { controller = "Home", action = "Index", id = "" }


Look at line 7. Isn’t it familiar? It is one of the ASP.NET framework extensions. You could add .aspx or whatever you want from ASP.NET framework extensions. It is already registered into the Default route so the requests will be mapped to the ASP.NET framework.

I hope that this is the solution you are looking for your problem.

After the release of ASP.Net MVC RC 2, we are now waiting for the RTM release but some of us wanna use RC 2 already... But how to deploy it on a shared hosting acount is the mind-exploding problem...
@ 12-18-2010
by Tugberk Ugurlu

UPDATE on 2011, 02.26

I have wrote another blog post on ASP.NET MVC Deployment problems you might have related to your server. If you are still having problems (especially, if you are getting 404 exceptions for extensionless URLs), you might want to have a look at on "Running ASP.NET MVC Under IIS 6.0 and IIS 7.0 Classic Mode : Solution to Routing Problem"

asp-net-mvc-3.gifOn the 10th of December in 2010, Microsoft ASP.Net MVC team has released the MVC 3 RC 2 and it has some good stuff inside which RC 1 didn't have. It is not so much different but there are some breaking changes, especially ViewBag thing.

You could find more information about ASP.Net MVC RC 3 goodies on ScootGu's blog post or Phil Haacked blog post.

The MVC 3 RC 2 has come from go-live-license so you can use this in production if you wish. But the main problem rises here if you are in a shared hosting environment. As you know, shared hosting providers are not willing to install the new releases unless it is for sure that there is no detected bug in the package.

I thought that would be a big problem for me [because I am still in shared hosting environment :)] but deploying the necessary assemblies as manually is the solution. Scott Hanselman has a great post on how to deploy an MVC 3 application into a shared hosting environment. The article covers all the necessary steps. One problem is that if you do exactly as it is there, you will sure have a problem if you are deploying the RC 2 of the MVC 3.

The yellow screen of death will give you the following error;

Could not load file or assembly 'System.Web.WebPages.Deployment, Version=, Culture=neutral, PublicKeyToken=31bf3856ad364e35' or one of its dependencies. The system cannot find the file specified.

The error will be thrown by the system because it needs System.Web.WebPages.Deployment.dll as well. The solution of this little problem is simple;

Navigate to C:\Program Files\Microsoft ASP.NET\ASP.NET Web Pages\v1.0\Assemblies (this could be C:\Program Files (x86)\Microsoft ASP.NET\ASP.NET Web Pages\v1.0\Assemblies on Windows 7) inside the windows explorer and you will see some files inside the folder;

You need those 6 dll files. In addition to that you will also need System.Web.Mvc.dll (version 3.0.11209.0). You will be able to find that dll file by navigating to C:\Program Files\Microsoft ASP.NET\ASP.NET MVC 3\Assemblies (that should be C:\Program Files (86x)\Microsoft ASP.NET\ASP.NET MVC 3\Assemblies in Windows 7 [I'm not sure though])

Finally you should all have the following dlls in hand;

  • Microsoft.Web.Infrastructure
  • System.Web.Razor
  • System.Web.WebPages
  • System.Web.WebPages.Razor
  • System.Web.Helpers
  • System.Web.WebPages.Deployment (If you are deploying MVC RC 2, this assembly is necessary to deploy)
  • System.Web.Mvc

I made a copy of those dlls and put them together inside a folder so that I could reach them easily whenever I need them;


We have all the necessary files in our hands and so what now !

There are some conventions here that you could choose. The way I follow is that;

  • I used built in Visual Studio Publish tool to publish my application to the production side.
  • After publishing was complated, I simply copied those 7 dll files into the bin folder inside the root directory of my application.

Visual Studio 2010 Publish Tool

That was it ! [Of cource I didn't put the System.Web.WebPages.Dployment.dll into the production side and I got the error firstly :)]

Finally, my bin folder has the necessary assembly files to run the application;


ASP.Net Chart Control On Shared Hosting Envronment (Parser Error) - Deployment of Chart Controls On Shared Hosting Environment Properly...
@ 03-13-2010
by Tugberk Ugurlu

[This Article is for those who can manage to run Chart Control on Local Server but not on Web Server]

Chart Control of ASP.Net 3.5 is very handy way to get statictical data as charts. There are variety of ways to display data with Chart Control. Also it is extramely simple to adapt it to your project. But as I hear from so many ASP.Net user nowadays, there might be some problems when it comes to publish it on your web server, especially on shared hosting servers !

After you install the Chart Control, in order to run ASP.Net chart control on your project, you need to configure your web.config file on your root directory which you have already done (I guess !). If you do that properly, you are able to run it on your local server perfectly. But it is not enough for you to be good to go on your web server.

You need to have Chart Control installed on your web server in order to run it on web !

It is easy to do that if you have your own server but for those who have their website files on a shared hosting service, it is a bit hard. But you do not need to beg your hosting provider to make it be installed on server. Only you need to do is to make proper changes on your web.config file and believe me those changes are much more simple than you think ! Of Course, some references is needed to be added to the Bin Folder on your root directory !

Solution :

  1. Follow this directory on windows explorer:

    C:\Program Files\Microsoft Chart Controls\Assemblies

  2. You will see 4 DLL files inside the folder. Two of those files are for Windows Applications and two of them for Web Applications. We need web application dll files so copy the dll files which are named 'System.Web.DataVisualization.Design' and 'System.Web.DataVisualization'

  3. Paste those dll files into the Bin folder on the root directory of your Web Application.

  4. Secondly, open the Web.Config file on the root directory of your web application.
  5. Find the <appSettings> node. You have a key add inside this just like below;

    <add key="ChartImageHandler" value="storage=file;timeout=20;dir=c:\TempImageFiles\;" />

    Replace this tag with the new one as below;

    <add key="ChartImageHandler" value="storage=file;timeout=20;"/>

    Save the changes on your Web.Config file and close it. Now copy the two dll inside the bin folder and replace the Web.Config file on your server with your new Web.Config file.

That's it !

Now you should be able to run the Chart Control on your Web Server without begging your hosting provider :) If you have any problem with this, I recommend you to check the following codes if they exist on your Web.Config file or not;












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