Chapter 3 Command Line Interface

--self-contained Self-contained applications include the .NET runtime your application specifies so that it doesn’t need to be installed on the target machines. This eliminates the risk of having to install multiple versions of the .NET runtime on a

machine, potentially causing conflicts. Shipping the .NET runtime with your application greatly simplifies installation, but it does come with a warning. Software contains bugs, especially in complex software like .NET; these bugs can show up pretty late in their lifespan and potentially cause severe security issues. Companies like Microsoft are usually quite fast to fix those security issues and push out an update. If you are packaging a specific .NET runtime version with your app, it is up to you as application developer

to follow up on those .NET updates and update your application with the new version of the .NET runtime when needed. In other words, you are responsible for replacing vulnerable .NET binaries in your application.

--no-self-contained does not ship the .NET runtime with the application. In this case, the application relies on the version of the .NET runtime installed on the user’s machine.

Dotnet Run

Dotnet run runs your application. It builds the application using dotnet build and launches the application.

Listing 3-16.  Documentation on dotnet run

Usage:

dotnet [options] run [[--] <additional arguments>...]]

56

57

Chapter 3 Command Line Interface

Dotnet run executes the binaries in the bin/<config>/<TFM> folder. This is where the output of the build command is put. In case of .NET 6, this could be /bin/<Configuration>/net6.0. Other frameworks can be specified by using the --framework parameter. A configuration can be specified by using the --configuration parameter. Listing 3-17 shows a complete example of a dotnet run command.

Listing 3-17.  Running a .NET 6 application using CLI

dotnet run --configuration Release --framework net6.0 --project

.\CliDemo.csproj

Dotnet Test

Dotnet test is used to run unit tests included in a project.

Listing 3-18.  dotnet test documentation (shortened for brevity)

Usage:

dotnet [options] test [<PROJECT | SOLUTION>...]

Arguments:

<PROJECT | SOLUTION> The project or solution file to operate on. If a file is not specified, the command will search the current directory for one.

58

Chapter 3 Command Line Interface

Dotnet test commands trigger a dotnet build after which it executes any unit tests it finds. It supports any test framework that has support for .NET 6, for example, MSTest, NUnit, XUnit, etc. Every test that was run by the tool will print its result; after all tests are run, the dotnet test command will return to either 0 (all tests successful) or 1 (at least one test failed). Figure 3-8 shows an example output of dotnet test.

Figure 3-8.  Example output of dotnet test

In the screenshot, you can see that four tests passed, while one failed. The tests in this sample project are written using NUnit; dotnet test automatically picks up on this and uses the correct adapter. Should it not find the correct adapter, or you want to use a custom one, you can use the --test-adapter-path option of the dotnet test command. The custom adapter needs to be named *.TestAdapter.dll for it to be picked up by the

.NET CLI tooling. Figure 3-6 also shows that the first step in running the test command is verifying if dependencies need to be restored or if the project needs to be compiled.

After fixing the failing unit test, we get the result shown in Figure 3-9.

Figure 3-9.  Passing all unit tests

Other often used options in dotnet test are:

59