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

Asp.Net Core applications are self-hosted. The Host process in which it will be executed needs to  implement the IWebHost interface.

This Host process /  IWebHost implementation is in charge of Application Startup as well as it's Lifecycle. The Host process has to be configured

to use a particular HTTP Server which will handle the Request. 

to use certain Middleware components for the Application Request-Response Pipeline. 

to create the Services that will be needed by Application. 

In the ASP.Net Core MVC Project Template, the Program.cs file comes with the following code which builds and launches the Host / IWebHost.

The IWebHost can be launched 

• in a blocking manner by calling the Run() method.
• in a non-blocking manner by calling the Start() method. 

HTTP Server  

The Host process can use one of the following 2 HTTP Servers

• Kestrel (Cross Platform)
• WebListener (Windows Only)

This HTTP Server listens to the request and forwards it to our ASP.Net Core Application for execution.

In Production, these HTTP servers should not be external facing. They should be behind a Proxy/Reverse Proxy like IIS on Windows, Apache on Linux etc which will forward the request to it. 

(IIS has an ASP.Net Core Module which forwards the request to the HTTP Server being used by Host of our ASP.Net Core application) 

In the above code, the UseKestrel() method indicates the the Host process will use Kestrel as the HTTP Server. The UseIISIntegration() method indicates that IIS will be used as Reverse Proxy. 

Configuring Middleware 

The IWebHost can be configured by providing a Configure() method, or specifying a Startup class which will have the method. 

The Configure() method is used to add Middleware components to the Application Request-Response Pipeline. Think of Middleware components as the lightweight .Net Core versions of .Net Framework's  HttpModules. These Middleware Components perform certain actions on the incoming request and then pass it onto the next Middleware Component. Or they may handle the Incoming Request themselves and create and send back the Response instead of passing it on to the next Middleware Component. 

In the ASP.Net Core MVC Project Template, the Startup.cs file comes with the following code in the Configure() methods adding some of the Middleware Components by default. 

Configuring Services 

The IWebHost Services can be configured by providing a  ConfigureServices() method, or specifying a Startup class which will have the method. 

In the ASP.Net Core MVC Project Template, the Startup.cs file comes with the following code in the ConfigureServices() methods adding some of the Services by default. 

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.

Restful WebServices / API's - proper use of HTTP Verbs and HTTP Status Codes

While writing code to consume Restful Web API's, as well as seeing some of the Restful Web API's written in some of the companies I've worked with, I get frustrated at times. I see a lot of implementations where  basic, simple principles of a Restful Service are not followed. The 2 common issues that i see a lot are

• Incorrect HTTP Verb is used. HTTP Post is used all the time. Even when it is to Get or Delete a resource, a method/url called GetCustomer or DeleteCustomer will be written and it expects a request Posted to it.
• Incorrect HTTP Status Codes are returned. Sometimes Status Code 200 is returned all the time with the error message in the response body. 

I thought I'd write a quick blog as a reference to how the Restful Web Services should be implemented, the verbs which should be used, and the different HTTP Status Codes returned for different scenarios.

Let's assume i have a Restful Web Api, called http://mywebapi.com/Api. It can be used to create/update/get/delete Customers.

Get a Customer

URL:  http://mywebapi.com/api/customer/{customerId}
Http Verb: Get

• If a customer with the provided id is not found, return HTTP Status Code of 404 (Not Found)
• If a customer is found, return customer with HTTP Status Code of 200 (OK).

Get a List of Customer

URL:  http://mywebapi.com/api/customer
Http Verb: Get

• Return the list of Customer with HTTP Status Code of 200 (OK). (If no customer was found, the list will just be empty.)

Create a Customer:

URL:  http://mywebapi.com/api/customer

Http Verb: Post

HTTP Request Body: The Customer object in Json format.

• If the Customer object can not be read/parsed from the HTTP Request Body, return HTTP Status code of 400 (Bad Request). 
• If the Customer object can not be created/saved in the DB, Http Status Code of 500 (Internal Server Error)
• If the Customer object is created, return HTTP Status Code of 201 (Created) + ideally the url of the new customer, for e.g. http://mywebapi.com/api/customer/104

Update a Customer:

URL:  http://mywebapi.com/api/customer/{customerId}

Http Verb: Put 

HTTP Request Body: The Customer object in Json format.

• If the Customer object can not be read/parsed from the HTTP Request Body, return HTTP Status code of 400 (Bad Request). 
• If a customer with the provided id is not found, return HTTP Status Code of 404 (Not Found)
• If the Customer object can not be updated/saved in the DB, Http Status Code of 500 (Internal Server Error)
• If the Customer object is created, return HTTP Status Code of 204 (No Content) 

Delete a Customer

URL:  http://mywebapi.com/api/customer/{customerId}

Http Verb: Delete

• If a customer with the provided id is not found, return HTTP Status Code of 404 (Not Found)
• If the Customer object can not be updated/saved in the DB, Http Status Code of 500 (Internal Server Error)
• Return HTTP Status Code of 200 (OK) + ideally the Customer Object which was deleted. 

Note:

SOAP, which used to be the primary standard for Message and Data exchange on the web, has been steadily replaced by Restful Services in the last few years, largely owing to it's simple design. 

In the .Net world, ASMX and WCF were used for creating SOAP Web Services and nowadays, ASP.Net MVC Web API is used for creating Restful Web Services. 

Angular 2 - Initial Impression

After working mainly with ASP.Net MVC for Web UI and some other JavaScript libraries, i finally got around to taking a look at Angular 2.

In this post i'll post my initial impressions and will dig deeper into Angular 2 in future posts.

First thing that got my attention is the Typescript Language, which is the language of choice for Angular 2. Typescript is a language developed by Microsoft and is a sort of an abstraction over JavaScript. Any code that is written in TypeScript eventually gets compiled/transpiled into JavaScript.  TypeScript felt closer to and Object Oriented Language like C# or Java, rather than the messy JavaScript. It has concepts like Classes, Constructors, Interfaces, Properties, Methods, Events, Strongly typed data types. As my main programming language has been C#, I found Typescript to be a pretty cool language which makes writing client side code a breeze. However, ppl who may have a a JavaScript background might have a different opinion about TypeScript..


Another thing that stood out was the discarding of the MVC / MVVM architecture which has been the trend in UI in the last few years (ASP.Net MVC, AngularJS, etc.) and using a component based architecture. Basically, the UI is broken down into smaller pieces and these pieces need to be implemented as a Component. A Component is  a TypeScript Class (with a Component Directive) and it would have it's UI html fragment in a separate Template file. The properties, methods, events and any logic would be in the TypeScript Class and the Template would bind to data in these as well as call it's methods and events. For those of you who have experience working with ASP.Net Web Forms, it might feel eerily similar to User Controls, with the UI Template file feeling like the UI *.ascx and the Component *.ts file feeling like the Code-Behind *.ascx.cs.

These Components could then be nested under other Components or put in directly under the Root Component, which would be loaded/bootstrapped into an .html page.

An application could have additional Service class, which could perform tasks like getting data from a Web Service. Components could have instantiate a Service Class and use it's methods to get Data or alternatively, the Services could be declared at the Root Component layer and then injected into the Component via the Constructor.


My initial impression of Angular 2 has, surprisingly, been very positive and am looking forward to doing a bit of deep diving into it.