.NET Core

Understanding ASP.NET Core 3.x

Exploring the Project Structure of ASP.NET Core 3

The Project File

These are project files of an empty project.

The Main Method

Program.cs contains Main method that is the entry point for the application.

Dependency Injection

Line 20 to 22 show the options to add services for dependency injection.

Configuring Dependency Injection

IOC container refers to Inversion of Control container. The container manages the lifetime of objects.

Transient

A transient container means instance of the type is created everything it is asked for.

Scoped

A scoped container means the instance will live until the web request is completely handled.

Singleton

A singleton lifetime means once an instance is created, the same instance will be supplied until the app closes.

Add a service as singleton at Startup.

Dependency Injection opens great opportunity for unit testing.

First add an interface service to Startup. Second the interface service can be used by a controller.

This approach makes the complexities about the lifetime of objects go away. It is no longer tied to a specific service e.g. ConferenceApiService or ConferenceMemoryService. We can easily swap out the service in Startup.cs allowing us to unit test easily.

Hence, no “hard” dependencies.

Configuring the Pipeline

Browsers make request through the pipeline. In the pipeline there could be middleware such as Auth middleware, MVC middleware, Static Files middleware, and etc… Source: Pluralsight Understanding ASP.NET Core 3.x by Roland Guijt

The Startup.cs Configure() method is where we configure the pipeline.

Routing

This example shows routing using MapGet vs using MapControllerRoute which is using

Adding Middleware

This is an example of adding middleware. For context, refer to the above section on the pipeline.

Launch Profiles

[Couldn’t find the option to change launch profiles]

Environments

Project Options has environment development. The IWebHostEnvironment will all referencing

The wwwroot Folder

This folder allows us to put any web content that is publicly accessible such as img, js, css.

Working with Packages and Libraries

Packages with NuGet and NPM

NuGet is specifically for .NET. Source: Pluralsight Understanding ASP.NET Core 3.x by Roland Guijt

Working with NPM

Add a package.json using the New File option.

LibMan

<Skipped for now>

Bundler and Minifier

<Skipped for now>

Using Task Runners

<Skipped for now>

Understanding ASP.NET Core 3 MVC

<skipped due to time constraint>

Blazor and SignalR

<skipped due to time constraint>

Setting up a Web API

<skipped due to time constraint>

What is .NET Core?

.NET Core isn’t tied to Windows unlike .NET Framework.

Source: Pluralsight Understanding ASP.NET Core 3.x by Roland Guijt

CoreCLR contains functionality of .NET Core. It has type system, garbage collector, and other services.

CoreFX is the framework libraries all kind of types. It is like the base class library.

The .NET Core CLI

How to use CLI to build application refer to Pluralsight Understanding ASP.NET Core 3.x by Roland Guijt > Chapter 7 Developing Applications Across Frameworks and Operating Systems > dotnet: The .NET Core CLI

Managing .NET Core Versions

$ dotnet --info

View the versions.

There is a separation between SDKs installed and runtimes installed.

ASP.NET Core Topology

Request

First, browser hits the web server IIS. Then IIS invokes dotnet runtime at initial startup which will load the CLR. Then CLR looks for an entry in App. The App then starts an internal web server in the application called Kestrel. Then the request is route from IIS to Kestrel. After which, IIS just sends the request to Kestrel. Finally, all request is pushed through the pipeline that is configured in the Startup.cs. In the pipeline, there are middle wares.

Response

From pipeline → Kestrel → IIS → Browser.

To configure Kestrel such as AddServerHeader etc…

Framework Dependent Deployments

Publish and run using dotnet cli.

This is a framework dependent process.

Self-contained Deployments

Different from the above framework dependent approach, we can have a distribution of this app as self contained. Put another way, the .NET Core and runtime will be included. Hence, no need to pre-install on the server that runs it.

Follow the video to publish a self-contained app, Pluralsight Understanding ASP.NET Core 3.x by Roland Guijt > Chapter 8 Deploying ASP.NET Core 3 Applications > Self-contained Deployments.

$ dotnet publish -c Release -r osx-x64 --self-contained

The command to use in terminal is above.

-c Release means the Release

-r osx-x64 is the RID for mac

self-contained is to generate it for self-contained.

• Commands for dotnet publish https://docs.microsoft.com/en-us/dotnet/core/tools/dotnet-publish
• Example of deploying self-contained with mac os https://docs.microsoft.com/en-us/dotnet/core/deploying/
• Docs on RID https://docs.microsoft.com/en-us/dotnet/core/rid-catalog

IIS

IIS is a full-blown web server. Image running a self-contained app in command line, what if it runs into error? Hence, we need a full-blown web server like IIS that can restart when met with errors.

After publishing, we will have web.config. It is meant for IIS.

Reference

Great course for understanding .NET Core https://app.pluralsight.com/library/courses/understanding-aspdotnet-core-3x