dotnet-core - Softsolution Sahand

.NET Core Overview

.NET Core is a new version of .NET Framework, which is a free, open-source, general-purpose development platform maintained by Microsoft. It is a cross-platform framework that runs on Windows, macOS, and Linux operating systems.

.NET Core Framework can be used to build different types of applications such as mobile, desktop, web, cloud, IoT, machine learning, microservices, game, etc.

.NET Core is written from scratch to make it modular, lightweight, fast, and cross-platform Framework. It includes the core features that are required to run a basic .NET Core app. Other features are provided as NuGet packages, which you can add it in your application as needed. In this way, the .NET Core application speed up the performance, reduce the memory footprint and becomes easy to maintain.

What is the middleware in .NET Core

What is the middleware in .NET Core and how to set a middleware?
Answer:
Middleware is just a simple class that consists of encapsulated information into an application pipeline to deal with the https request response pipeline.
Every part of this class has the option to pick whether to give the request to the next
pipeline, and can play out specific activities when the following request passes in the
pipeline.
In this case Request delegates are utilized to construct the request pipeline.
The request delegates handle every HTTP request.
So we should create for the specific purpose of of single middleware.
Middleware Order of Execution
The middleware Order of Execution plays a very important role so you have to take care of
it very precisely, otherwise you may get unexpected behavior.
So suppose you have 3 middleware – M1, M2, M3 in sequential order, then it will invoke in
the same order and then respond in the reverse direction.
Lets take another example here.

1. UseAuthentication();
2. app.UseAuthorization();

Here we have set first authentication then authorization, so the order matters, because in
real projects we do first authentication, then authentication.
Please refer to this image as it is taken from MS doc reference.
Create middleware using IApplicationBuilder
We can create middleware in the Configure method of the Startup class using
IApplicationBuilder interface.
Here in this following example I will add a simple middleware using Run method that will
return a string “Hello my first middleware,” on every request.

 public class Startup {
 public Startup() {}
 public void Configure(IApplicationBuilder app,
IHostingEnvironment env, ILoggerFactory loggerFactory) {
 // here i have configure middleware using
IApplicationBuilder with Run merhod.
 // I will explain Run method in details just a bil.
 app.Run(async (context) => {
await context.Response.WriteAsync("Hello my first
middleware");
 });
 // I have removed hereother code for the clarity..
 }
 }

In this example I have used Run() method. This is a extension merhod of IApplicationBuilder
interface.
Here I have created middleware using lambda expression, but we can also create it using a
private method like this,

 public class Startup {
 public Startup() {}
 public void Configure(IApplicationBuilder app,
IHostingEnvironment env) {
 app.Run(TestMiddleware);
 }
 private Task TestMiddleware(HttpContext context) {
 return context.Response.WriteAsync("Hello
TestMiddleware");
 }
 }

what is application pipline?

In software engineering, a pipeline consists of a chain of processing elements
(processes, threads, coroutines, functions, etc.), arranged so that the output of each
element is the input of the next; the name is by analogy to a physical pipeline.

.NET Core cli commands

dotnet restore

Restores the dependencies and tools of a project.

Description

The dotnet restore command uses NuGet to restore dependencies as well as project-specific tools that are specified in the project file. In most cases, you don’t need to explicitly use the dotnet restore command, since a NuGet restore is run implicitly if necessary when you run the following commands:

dotnet new

Creates a new project, configuration file, or solution based on the specified template.

Description

The dotnet new command creates a .NET project or other artifacts based on a template. The command calls the template engine to create the artifacts on disk based on the specified template and options.

Implicit restore

You don’t have to run dotnet restore because it’s run implicitly by all commands that require a restore to occur, such as dotnet new, dotnet build, dotnet run, dotnet test, dotnet publish, and dotnet pack. To disable implicit restore, use the --no-restore option.

The dotnet restore command is still useful in certain scenarios where explicitly restoring makes sense, such as continuous integration builds in Azure DevOps Services or in build systems that need to explicitly control when the restore occurs.

dotnet build

Builds a project and all of its dependencies

Description

The dotnet build command builds the project and its dependencies into a set of binaries. The binaries include the project’s code in Intermediate Language (IL) files with a .dll extension. Depending on the project type and settings, other files may be included, such as:

An executable that can be used to run the application, if the project type is an executable targeting .NET Core 3.0 or later.
Symbol files used for debugging with a .pdb extension.
A .deps.json file, which lists the dependencies of the application or library.
A .runtimeconfig.json file, which specifies the shared runtime and its version for an application.
Other libraries that the project depends on (via project references or NuGet package references).

For executable projects targeting versions earlier than .NET Core 3.0, library dependencies from NuGet are typically NOT copied to the output folder. They’re resolved from the NuGet global packages folder at run time. With that in mind, the product of dotnet build isn’t ready to be transferred to another machine to run. To create a version of the application that can be deployed, you need to publish it (for example, with the dotnet publish command). For more information, see .NET Application Deployment.

For executable projects targeting .NET Core 3.0 and later, library dependencies are copied to the output folder. This means that if there isn’t any other publish-specific logic (such as Web projects have), the build output should be deployable.

Implicit restore

Building requires the project.assets.json file, which lists the dependencies of your application. The file is created when dotnet restore is executed. Without the assets file in place, the tooling can’t resolve reference assemblies, which results in errors.

For information about how to manage NuGet feeds, see the dotnet restore documentation.

This command supports the dotnet restore options when passed in the long form (for example, --source). Short form options, such as -s, are not supported.

Executable or library output

Whether the project is executable or not is determined by the <OutputType> property in the project file. The following example shows a project that produces executable code:

For information about how to manage NuGet feeds, see the dotnet restore documentation.

dotnet build-server

Interacts with servers started by a build.

Synopsis

dotnet build-server shutdown [--msbuild] [--razor] [--vbcscompiler] dotnet

 build-server shutdown -h|--help 

dotnet build-server -h|--help

Commands

shutdownShuts down build servers that are started from dotnet. By default, all servers are shut down.

Options

-?|-h|--helpPrints out a description of how to use the command.

--msbuildShuts down the MSBuild build server.
--razorShuts down the Razor build server.
--vbcscompilerShuts down the VB/C# compiler build server.

dotnet run

Runs source code without any explicit compile or launch commands.

Description

The dotnet run command provides a convenient option to run your application from the source code with one command. It’s useful for fast iterative development from the command line. The command depends on the dotnet build command to build the code. Any requirements for the build, such as that the project must be restored first, apply to dotnet run as well.

 !Note

dotnet run doesn't respect arguments like /property:property=value, which are respected by dotnet build.

Output files are written into the default location, which is bin/<configuration>/<target>. For example if you have a netcoreapp2.1 application and you run dotnet run, the output is placed in bin/Debug/netcoreapp2.1. Files are overwritten as needed. Temporary files are placed in the obj directory.

If the project specifies multiple frameworks, executing dotnet run results in an error unless the -f|--framework <FRAMEWORK> option is used to specify the framework.

The dotnet run command is used in the context of projects, not built assemblies. If you’re trying to run a framework-dependent application DLL instead, you must use dotnet without a command. For example, to run myapp.dll, use:

<span class="hljs-keyword">dotnet</span> myapp.dll

Implicit restore

You don’t have to run dotnet restore because it’s run implicitly

dotnet test

NET test driver used to execute unit tests.

Description

The dotnet test command is used to execute unit tests in a given solution. The dotnet test command builds the solution and runs a test host application for each test project in the solution. The test host executes tests in the given project using a test framework, for example: MSTest, NUnit, or xUnit, and reports the success or failure of each test. If all tests are successful, the test runner returns 0 as an exit code; otherwise if any test fails, it returns 1.

For multi-targeted projects, tests are run for each targeted framework. The test host and the unit test framework are packaged as NuGet packages and are restored as ordinary dependencies for the project.

Where Microsoft.NET.Test.Sdk is the test host, xunit is the test framework. And xunit.runner.visualstudio is a test adapter, which allows the xUnit framework to work with the test host.

Implicit restore

You don’t have to run dotnet restore because it’s run implicitly.

dotnet publish’

Publishes the application and its dependencies to a folder for deployment to a hosting system.

Description

dotnet publish compiles the application, reads through its dependencies specified in the project file, and publishes the resulting set of files to a directory. The output includes the following assets:

Intermediate Language (IL) code in an assembly with a dll extension.
A .deps.json file that includes all of the dependencies of the project.
A .runtimeconfig.json file that specifies the shared runtime that the application expects, as well as other configuration options for the runtime (for example, garbage collection type).
The application’s dependencies, which are copied from the NuGet cache into the output folder.

The dotnet publish command’s output is ready for deployment to a hosting system (for example, a server, PC, Mac, laptop) for execution. It’s the only officially supported way to prepare the application for deployment. Depending on the type of deployment that the project specifies, the hosting system may or may not have the .NET shared runtime installed on it. For more information, see Publish .NET apps with the .NET CLI.

Implicit restore

You don’t have to run dotnet restore because it’s run implicitly.

For information about how to manage NuGet feeds, see the dotnet restore documentation.

MSBuild

The dotnet publish command calls MSBuild, which invokes the Publish target. If the IsPublishable property is set to false for a particular project, the Publish target can’t be invoked, and the dotnet publish command only runs the implicit dotnet restore on the project.

Any parameters passed to dotnet publish are passed to MSBuild. The -c and -o parameters map to MSBuild’s Configuration and PublishDir properties, respectively.

The dotnet publish command accepts MSBuild options, such as -p for setting properties and -l to define a logger. For example, you can set an MSBuild property by using the format: -p:<NAME>=<VALUE>.

You can also set publish-related properties by referring to a .pubxml file. For example:

<span class="hljs-keyword">dotnet</span> <span class="hljs-keyword">publish</span><span class="hljs-parameter"> -p</span>:PublishProfile=FolderProfile

The preceding example uses the FolderProfile.pubxml file that is found in the <project_folder>/Properties/PublishProfiles folder. If you specify a path and file extension when setting the PublishProfile property, they are ignored. MSBuild by default looks in the Properties/PublishProfiles folder and assumes the pubxml file extension. To specify the path and filename including extension, set the PublishProfileFullPath property instead of the PublishProfile property.

The following MSBuild properties change the output of dotnet publish.

PublishReadyToRunCompiles application assemblies as ReadyToRun (R2R) format. R2R is a form of ahead-of-time (AOT) compilation. For more information, see ReadyToRun images.To see warnings about missing dependencies that could cause runtime failures, use PublishReadyToRunShowWarnings=true.We recommend that you specify PublishReadyToRun in a publish profile rather than on the command line.
PublishSingleFilePackages the app into a platform-specific single-file executable. For more information about single-file publishing, see the single-file bundler design document.We recommend that you specify this option in the project file rather than on the command line.
PublishTrimmedTrims unused libraries to reduce the deployment size of an app when publishing a self-contained executable. For more information, see Trim self-contained deployments and executables. Available since .NET 6 SDK.We recommend that you specify this option in the project file rather than on the command line.

For more information, see the following resources:

dotnet pack

Packs the code into a NuGet package.

Description

The dotnet pack command builds the project and creates NuGet packages. The result of this command is a NuGet package (that is, a .nupkg file).

If you want to generate a package that contains the debug symbols, you have two options available:

--include-symbols – it creates the symbols package.
--include-source – it creates the symbols package with a src folder inside containing the source files.

NuGet dependencies of the packed project are added to the .nuspec file, so they’re properly resolved when the package is installed. If the packed project has references to other projects, the other projects are not included in the package. Currently, you must have a package per project if you have project-to-project dependencies.

By default, dotnet pack builds the project first. If you wish to avoid this behavior, pass the --no-build option. This option is often useful in Continuous Integration (CI) build scenarios where you know the code was previously built.

!Note

In some cases, the implicit build cannot be performed. This can occur when GeneratePackageOnBuild is set, to avoid a cyclic dependency between build and pack targets. The build can also fail if there is a locked file or other issue.

You can provide MSBuild properties to the dotnet pack command for the packing process. For more information, see NuGet pack target properties and the MSBuild Command-Line Reference. The Examples section shows how to use the MSBuild -p switch for a couple of different scenarios.