ASP.NET 5 on Azure Websites

Something cool to try out – you can run your ASP.NET vNext applications on Windows Azure Websites already today. Yes, you can take Visual Studio 14 CTP, create ASP.NET vNext application and deploy it to cloud. In this posting we will sniff around in Azure Websites to see how ASP.NET vNext applications run there.

Current MVC application on Azure Websites

After deploying regular ASP.NET MVC application to Azure Websites we can see the following directory structure when browsing our web site over FTP. All regular stuff – there is wwwroot folder that is root for web site and under this we can see classic folders and files.

In files list you can see some DLL files in bin folder. Nothing special.

Targeting CoreCLR

Now suppose we have ASP.NET MVC 6 web application and we want it to run on CoreCLR. In project properties window can change target framework. On screenshot below you can see how CoreCLR (ASP.NET Core 5.0) is selected as active target framework.

CoreCLR uses less references to different libraries and it is possible you have to define some dependencies in project.json file to get missing libraries to your project. If application build successfully you can deploy it to Azure Websites like you deploy any other web application.

ASP.NET MVC 6 on Azure Websites

After deploying ASP.NET MVC 6 application to Azure Websites we will see totally different picture in our FTP client.

So, here is the folder structure:

  • approot – all stuff needed for Roslyn to build application,
  • approot/packages – all NuGet packages that our application needs are here,
  • approot/src – all source files and views are here, there’s nothing in bin folder
  • wwwroot – root folder of our web application.

Take a look at screenshot above again. You can see that bin folder under wwwroot is selected and there is only one small DLL file – AspNet.Loader.dll. This is the only binary file in our bin folder and from this file starts the show.

K configuration on server

Our application loader in AspNer.Loader.dll needs some additional information about runtime version and files location. For this purpose there is file k.ini and it is located in root folder of web application.

Here is the example of k.ini


This small file tells to our loader how our application must run and where to find source to compile. This ini-file cannot be requested over browser and what’s more cool – all other configuration files are under approot folder and completely unaccessible through browser.

Wrapping up

ASP.NET vNext applications are deployed to cloud using different application structure. Application source files are deployed under approot folder that is not directly accessible from web. Under web root we have static files and k.ini. From public bin folder we can find our application loader. Our application is compiled to memory by Roslyn and all external libraries are included as NuGet packages.

Liked this post? Empower your friends by sharing it!

View Comments (3)

Related Post