Jump Start .Net Core - Day One

In 2016, Microsoft Corporation released a new framework version called .NET Core. But this time, Microsoft developed this framework or SDK not only for Windows operating system but also for other OSs like Linux and Mac. So, in other word, ASP.NET Core is not a closed source product; it is basically an open source SDK which allows developers to build and run the applications on any operation system.

Before trying to define the ASP.NET Core, we need to understand why this revaluation is done by Microsoft. For analyzing this, we need to see what it was before and how the web development world has changed during last 15 years.

ASP.NET Web Forms

Web Forms was released with the first version of the .NET Framework back in 2002. It was meant to appeal to two different kinds of developer groups.

The first group included web developers coming from Classic ASP, also called Active Server Pages, who were already building websites and web applications with a mix of static HTML and dynamic server-side scripting (usually VBScript) used by the framework to hide the complexity of interacting with the underlying HTTP connection and the web server. The framework also provided other services to implement some kind of state management, caching, and other lower-level concerns.

The second group consisted of a large number of WinForms application developers who were forced by changes in the market to start approaching the world of web development. Those developers didn't know how to write HTML. They were used to developing the UI of their applications by dragging elements onto the designer surface of an IDE. Web Forms was engineered by combining elements from both technologies. It turned out to be a framework where everything was abstracted: the elements of the HTTP connection (request and response), the HTML markup of UI elements, and the stateless nature of the web—this last one was via the infamous ViewState.

Over the years, many things have been changed. These new developers became more skilled and wanted to have more control over the HTML markup produced. And the web programming model has changed as well with more extensive usage of JavaScript libraries, with AJAX and with the introduction of mobile devices. But it was difficult for Web Forms to evolve.

• It was a huge, monolithic framework that was heavily coupled with the main abstraction layer System.Web.
• Given its programming model, which relied on Visual Studio, the release cycle of Web Forms was tied to its IDE and the full framework, so years passed between updates.
• The last limiting factor was the fact that Web Forms was coupled with Internet Information Services (IIS), which was even more difficult to upgrade because it was part of the operating system itself 

ASP.NET MVC

To try and solve the aforementioned issues, in 2009, Microsoft released a new web framework called ASP.NET MVC. It was based on the Model-View-Controller (MVC) pattern to keep a clear separation between business logic and presentation logic, allowing complete control over the HTML markup. In addition to this, it was released as a separate library, one not included in the framework. Thanks to this release model, and not relying 100% on the IDE for the design of the UI, it was possible to easily update it, keeping it more in line with the fast-paced world of web development.

But ASP.NET MVC, although solving the problem of the slow release cycle and removing the HTML markup abstraction, still suffered from a dependency on the .NET Framework and System.Web, which still made it strictly coupled with IIS and Windows.

ASP.NET Web API

Over time, a new web programming model appeared: instead of processing the data server-side and sending the fully rendered page to the browser, this new paradigm, later called Single-Page Applications (SPA), used mostly static web pages that fetched data via Ajax from the server and rendered the UI directly on the client via JavaScript. Microsoft needed to implement a lighter, web-aware version of the library it already had for remote communication, Windows Communication Foundation (WCF), so it released ASP.NET Web API.

This library was even more modular than the other libraries, and, probably because it was originally developed by the WCF team and not the ASP.NET team, it didn't rely on System.Web and IIS. This made Web API completely independent from the rest of ASP.NET and IIS, opening possibilities such as running it inside a custom host or potentially under different web servers.

OWIN and Katana

Now, with all these modular frameworks spreading around, there was the concrete risk that developers had to manage separate hosts for different aspects of modern applications. To avoid this becoming a real problem, a group of developers from the .NET community created a new standard, called OWIN, which stands for Open Web Interface for .NET, that defines the components of a modern web application and how those components interact. Microsoft released an OWIN-compliant web server, called Katana, and made sure its web frameworks worked inside it. Some problems still remained, however. 16

ASP.NET MVC, being tied to System.Web, couldn't run inside Katana. Also, all these frameworks, being developed by different teams and at different times, had different programming models. For example, both ASP.NET MVC and Web API supported dependency injection, but in different ways. If developers wanted to combine MVC and Web API inside the same application, they had to implement them twice.

What it brought to .NET Core

With the latest iteration of libraries, it was clear that the maximum potential of the full .NET framework had been reached. Still, many issues remained open:

• One couldn't run .NET applications on a non-Windows system.
• The dependency on the full framework made the .NET apps less suitable for high-density scenarios, like the cloud, where hundreds of applications run on a single machine and must scale up very fast.
• The complexity of the .NET project system prevented the development of .NET apps outside of Visual Studio.

It became clear that the only possible solution was to start from scratch, redesigning the ASP.NET framework to be fully modular with clearly implemented, generic foundations. It also needed to be cross-platform and based on an underlying .NET framework adhering to the same principles.

For these reasons, Microsoft completely rebuilt ASP.NET Core based on a new cross-platform .NET runtime, which later became .NET Core. Before going to further discussion, let’s first we define the .NET Core and ASP.NET Core.

.NET Core

The framework .NET Core 1.1 a is modular, cross-platform, cloud-optimized version of the .NET Framework, consisting of the CoreCLR and the implementation of the .NET Standard Library 1.6. One of the main features of this library is the ability to install only the features that are needed for the application you are building, reducing its footprint and the possibility of installing the library itself within the application. This makes it possible for applications built with different versions to co-exist on the same machine without the compatibility problems typical of the full .NET Framework.

ASP.NET Core

ASP.NET Core is a complete rewrite of ASP.NET, built with the goal of being cross-platform, completely open-source, and without the limitations of backward compatibility. Like .NET Core, ASP.NET Core is also built with a modular approach. This means the application you build can include only the needed features without taking on additional burdens. This is made possible by the new startup and execution environment, based on the Open Web Interface for .NET (OWIN) standard. In addition, ASP.NET Core comes with many interesting features that we are going to see throughout the book, like an integrated dependency injection system and a new application framework that unifies the programming models of ASP.NET MVC and Web API.

Installing .Net Core in Windows Operating System

If you are using Visual Studio 2017 version, then it is very much easy to install the .NET Core since this feature is already included in the Visual Studio 2017 installation package. So, just open the Visual Studio Installer and select the .NET Core Cross-platform Development workload and complete the installation.

 

If you are using Visual Studio 2015, then you need to install Visual Studio 2015 Update 3 and then download the .NetCore installer from the below link and install.

Building First .Net Core Application – Hello World

With so many operating systems and tools available, there are many ways to create a .NET Core application, but all the visual tools rely on the SDK to get things done. Here, you are going to build your first .NET Core application using the .NET command line interface (CLI).

The main entry point for the SDK is the .NET command. This command, depending on the verb used, can do lots of things, from acting as host and runner for the application to creating a new project, managing dependencies, and building applications.

Command-line tools

As an example, let's create a simple "Hello World" command-line application using the .NET CLI. Since the command-line tools are cross-platform, the following steps can be performed on any of the supported systems: Windows, Mac, or Linux.

Open the Command Prompt (or Terminal) and create an empty folder, calling it HelloWorldProg. Now, move to within that folder and run the following command in the command prompt – dotnet

 

Basically, this command checks the environment to see if .Net Core SDK is installed properly or not. If it is installed properly, then it shows its current version number and some other information as attached in the screen.

Now, it’s time to create a new project file for the program. For creating a new project, just type the command dotnet new in the command prompt.

After using this command, the below screen will appear which asks us to mention the type of project with the command. Since we want to create a console based program for the first time, we will use the command – dotnet new console

As per the above image, a console application has been created with two files – helloworld.csproj and program.cs. Now, we want to know what is written in program.cs file. For that, type the following command.

type program.cs and the output is shown below –

Now, before running the program, we need to restore the packages for this project. For that, run the below command –

dotnet restore

 

After successful restoration of packages, it is time to run the program. For that, execute the below command-

dotnet run

Now, let's change the code of the program.cs file as below and then run the code.

using System;
namespace helloworld {
    class Program {
        static void Main(string[] args) {
            Console.WriteLine("Hello World!");
            var name = Console.ReadLine();
            Console.WriteLine("Hello {0} Welcome to C# Corner.", name);
        }
    }
}

Here is the output.

 

You can read the next part here,

• Day 2 - Building .NET Core Basic Application With Visual Studio 2017