Tuesday, 30 August 2016

Hello ASP.Net Core/ .Net Core (Part 2 )



This is one in a series of posts about ASP.Net Core/.Net Core.

.Net Core CLI

.Net Core comes with a Command Line Interface, .Net Core CLI. We can run our ASP.Net Core application using this .Net Core CLI. If we navigate to our ASP.Net Core Application folder, and then run the command dotntet run , the .Net Core CLI will launch our ASP.Net Core Application.



We no longer need IIS or Visual Studio to run out Web Application.



In Addition to running our Application, .Net Core CLI can also build our application or get the NuGet packages.












This frees us from having to use Visual Studio IDE to build and debug our Web Application. We could use the free Visual Studio Code or any other text editor. The CLI commands can then be used for everything else. 

Hello ASP.Net Core/ .Net Core (Part 1 )


ASP.Net Core and .Net Core was released with much fanfare by Microsoft a few weeks ago. It has been described by Microsoft as  ".NET Core is a cross-platform, open source, and modular .NET platform for creating modern web apps, microservices, libraries and console applications." 

So, why did Microsoft have to come up with .Net Core/ ASP.Net Core ? What is different about it compared to .Net Framework? Why should we use it?

I'm going to write a few blogs articles discussing these and my thoughts about it. (I'm not going to be doing any tutorials on how to build applications using ASP.Net Core.).

Monolithic ASP.Net vs Modular ASP.Net Core


For ASP.Net, the Windows Server had to have .Net Framework, which consists of the Conmmon Language Runtime and Framework Class Libraries, as well as IIS installed. After that, one's ASP.Net application could run on the machine.

For ASP.Net Core, the various libraries are implemented separately rather than one big monolithic Framework and are made available as NuGet Modules. We individually select which Asp.Net Libraries we want and add them to our ASP.Net Core project.

This makes ASP.Net Core lack the simplicity of the ASP.Net but it provides a lot more flexibility. The various ASP.Net Core modules are developed by different teams and new versions of different modules could be released quite frequently, bug fixes could be released quite frequently and we could selectively upgrade just that particular library. Previously we had to wait for the next version of .Net Framework, e.g. .Net 4.5 or .Net 4.6 to come out. Also, when we upgraded to the new version, all of the libraries would get upgraded and not just the library we wanted.

This also gives ASP.Net Core applications a much smaller footprint as only the libraries we need are there rather than the whole huge .Net Framework.


Decoupled from IIS 


System.Web.dll is dead. It is no longer present in ASP.Net Core. This is actually a pretty big deal.

System.Web.dll was, in many ways, the heart of ASP.Net. It contained the class System.Web.HttpApplication (made available in the ASP.Net project via Gloabal.asax and Global.asax.cs) which represented the ASP.Net Application and it's Request-Response pipeline. This had a a collection of built-in Pipeline components(Http Modules) such as, Authentication/Authorization/Session etc. which used to inspect and the incoming request/outgoing response and modify it. Additionally, this was heavily coupled together with IIS 7 +.

In ASP.Net Core, we no longer have System.Web.dll or the System.Web.HttpApplication Class or other related classes. Consequently, we no longer need IIS for ASP.Net Core Applications. It can be self-hosted.

Also, we no longer have the Request-Response Pipeline that came with System.Web.HttpApplication, which many ppl thought had got too bloated with a lot of Http Modules and wasn't very efficient.

So, if there is no IIS or built in Request-Response Pipeline, how does ASP.Net Core process requests ?

Simple, we build our own Application Request-Response pipeline.  ASP.Net Core project have a Program.cs with a Main(), which is the entry point. In this, we use the WebHostBuilder class to configure and build an instance of  WebHost and then run it. This WebHost instance will then take care of handling and executing all requests.

When building the WebHost instance, we select what goes in our pipepline, such as modules for  MVC, Static Files, Authentication etc.



Cross Platform vs Windows Only 


Microsoft .Net Framework consists of a Runtime called  CLR and Libraries called FCL/Framework Class Library. Some of the libraries written in FCL specifically targetted the Windows Operating System. The CLR can also only run on Windows. So, with .Net Framework, we are pretty much tied to the Windows OS.

For .Net Core, Microsoft wrote a new Runtime called CoreCLR which can run on Linux, Windows, Mac OS X. The libraries for .Net Core called CoreFX, also don't have any Windows Specific dependency, making .Net Core/ ASP.Net Core truly multi-platform.