Originally posted on: http://geekswithblogs.net/stun/archive/2016/08/16/aspnet-core-blog-series-part-1.aspx
ASP.NET Core Getting Started
ASP.NET Core 1.0 runtime RTM was announced by the .NET Web Development and Tools Blog on
June 27th 2016
. .NET Core brings about significant changes, and I will start with introducing the new development workflow using Visual Studio 2015 (Update 3). I will slowly introduce the more complex changes in subsequent posts.
It has been over 2 years since I announced to write this blog series. I have been lazy and very busy since I became a father in October 2014. After putting it off for so long, I have found the motivation to begin writing this blog series. Another reason is that I believe .NET Core has reached a stable-enough milestone to write about without having to revise my blog posts continuously.
Software Requirements
Please install the following so you can try it out yourself as you read.
Visual Studio 2015 (FREE Community Edition is available)
Visual Studio 2015 (Update 3)
.NET Core 1.0.0 - VS 2015 Tooling Preview 2 (or later)
Git Source Control
Visual Studio IDE is not really needed anymore for developing .NET applications.
However, lets explore the .NET Core development workflow using Visual Studio for simplicity.
Create New ASP.NET Core Web Application
As great as Visual Studio is, it hides a lot of details and prevents developers from fully understanding how to setup a new project on their own. Instead, lets create a project from scratch, and compose the building blocks piece by piece.
Most readers will not see the point of this exercise. I do encourage you to follow these steps with an implicit faith in my assertion that it will become an essential knowledge in the future blog posts in the series. We will create an empty ASP.NET Core Web Application project instead of choosing the Web API or Web Application template.
Click File --> New --> Project in Visual Studio
Choose the ASP.NET Core Web Application (.NET Core) project template
Choose the Empty template.
Use the name AspNetCoreApp for the Visual Studio solution.
You will see a folder path like this AspNetCoreApp\src\AspNetCoreApp.
I have uploaded this to a Git repository (https://github.com/soelinn/learn-dotnet-core) on GitHub. Here is the list of files included.
Running from within Visual Studio
In Visual Studio's Solution Explorer, you will notice a few files and folder that you have not seen before in older ASP.NET projects.
Let's run the ASP.NET Core Web Application from Visual Studio by pressing Ctrl F5 to [Start Without Debugging]. It will open the URL http://localhost:52010 that displays "Hello World! We will now analyze the generated code, and figure out how things are wired up.
Running from Command Prompt
If the ASP.NET Core 1.0.0 - VS 2015 Tooling Preview 2 was installed as expected, you may be able to execute the ASP.NET Core Web Application from a regular Command Prompt.
Open Command Prompt from Windows's Start Menu by typing cmd.
Change directory to the Project folder path by typing cd C:\Users\{replace-with-your-account}\Desktop\AspNetCoreApp\src\AspNetCoreApp.
Type dotnet restore, and it will download necessary NuGet packages to execute the app.
Type dotnet run, and you will be instructed to point your browser to http://localhost:5000.
Visual Studio vs Command Prompt
At this point, you may have realized that the port numbers on which the application run are different between Visual Studio (port 52010) and Command Prompt (port 5000).
Questions
We will analyze the source code files to answer the following questions.
Why are we able to run an ASP.NET Core Web Application from the Command Prompt?
Where is the "Hello World!" message coming from when the app runs?
Why is the port number different between Visual Studio and Command Prompt?
#1 Program.cs
#2 Startup.cs
#3 Properties\launchSettings.json
Answer #1 - Console Application
The "old" original ASP.NET applications were class library assemblies (DLLs), and executed from within IIS or IIS Express, and didn't have a Main() function. Seeing the Main(string[] args) function defined in the Program.cs file indicates it is a .NET Console Application.
Readers who are familiar with Java development framework Spring (https://spring.io) will recognize that ASP.NET Core Web is very similar to the Spring Boot (http://projects.spring.io/spring-boot/) architecture. Spring Boot applications run as standalone Console applications, and Spring Boot has its own CLI (command line interface) tools.
Spring Boot architecture with its CLI (command line interface) is very DevOps friendly due to scriptability for managing applications. You may have heard that Microservices architecture is THE buzz word in the industry nowadays.
Answer #2 - OWIN Middleware
Despite not having any MVC Controller defined in the project, the ASP.NET Core App was still serving a "Hello World!" message. It is just a very simple OWIN middleware writing out the message to the Response stream in the Startup.cs class.
Answer #3 - launchSettings.json
From reading the launchSettings.json, we can see that there are two different types of launch settings defined. One is using the IISExpress command on port 52010, and another using Project command on port 5000.
We can infer that these new JSON files (global.json, launchSettings.json, and project.json) in the project affects the application's behavior.
Another thing to note is that these JSON files have corresponding JSON-schema files, which are visible when they are opened in the Visual Studio.
JSON Schema Locations
JSON File
Schema
launchSettings.json
http://json.schemastore.org/launchsettings
global.json
http://json.schemastore.org/global
project.json
http://json.schemastore.org/project
Summary
I want to wrap up this Part 1 so you can explore the generated project a little bit on your own.
Overall, we have witnessed that an ASP.NET Core Web Application project created from the Empty Project Template has a lot of configurations files and behavioral differences depending on how it is launched. The ASP.NET Core Web Application is now a Console Application instead of a class library like the legacy ASP.NET framework, and it is a major departure of its bloated past. ASP.NET team seems to be incorporating design architectures of well known battle-tested frameworks in the open source community.
In my next blog post for the series, I will explain the role of the JSON config files, and explore the ASP.NET Core runtime and tooling.