Comprehensive Guide to Running .NET Core Console Applications from Command Line

Overview of .NET Core Application Deployment Types

Before running .NET Core console applications, it's essential to understand the two primary deployment models: framework-dependent deployment and self-contained deployment. Framework-dependent deployment is the default approach where applications rely on the .NET Core runtime environment installed on the system. This deployment method generates smaller publish packages but requires the target machine to have the appropriate .NET Core runtime version installed.

Self-contained deployment packages the application together with the required .NET Core runtime, creating a complete independent package. While this approach results in larger publish packages, it enables direct execution on machines without .NET Core runtime installation, providing better environment independence.

Detailed Command Line Execution Methods

For framework-dependent applications, the execution command is dotnet yourapp.dll. Here, yourapp.dll represents the application's main assembly file, typically found in the publish output directory under bin/<configuration>/<target> path. For instance, a net6.0 application with Debug configuration defaults to output path bin/Debug/net6.0.

Self-contained application execution varies by operating system: Windows systems use yourapp.exe command for direct execution, while Unix/Linux systems employ ./yourapp command. Note that on Unix systems, executable permissions may need to be added first using chmod +x yourapp command.

In-depth Analysis of dotnet run Command

The dotnet run command offers a convenient approach to execute applications directly from source code without explicit compilation and launch commands. This command proves particularly valuable for rapid iterative development scenarios, relying on dotnet build command for code compilation, thus inheriting all build requirements.

Output files are written to the default location, specifically the bin/<configuration>/<target> directory. For example, running dotnet run for a netcoreapp2.1 application places output files in bin/Debug/netcoreapp2.1 directory. Files are overwritten as needed, with temporary files residing in the obj directory.

Key Parameter Options Explanation

The -c|--configuration <CONFIGURATION> parameter defines the build configuration, with Debug being the default for most projects, though this setting can be overridden within the project. Using Release configuration generates optimized versions.

The -f|--framework <FRAMEWORK> parameter becomes mandatory when projects specify multiple frameworks, used to designate the target framework. Example: dotnet run -f net6.0.

The --launch-profile <NAME> parameter enables specification of launch profiles, defined in launchSettings.json file, typically including environment configurations like Development, Staging, and Production.

Application Parameter Passing

To pass parameters to applications, employ the -- delimiter to distinguish between dotnet run command parameters and application parameters. For instance: dotnet run --configuration Release -- --help, where the --help parameter gets passed to the application.

For multiple framework scenarios, combine framework specification with parameter passing: dotnet run -f net6.0 -- arg1 arg2, executing the application under net6.0 framework while passing arg1 and arg2 as parameters to the application.

Practical Application Scenario Examples

The simplest approach to run projects in the current directory involves direct use of dotnet run command, utilizing default Debug configuration and current framework.

To execute projects with specific configurations, use: dotnet run --property:Configuration=Release, building and running the application using Release configuration.

For complex parameter passing scenarios, such as: dotnet run -f net6.0 -arg1 -- arg2 arg3, where -arg1 represents parameters passed to dotnet run (though this specific parameter might not be recognized), while arg2 and arg3 are parameters passed to the application.

Environment Variable Management

Environment variables can be applied to launched applications through multiple mechanisms, ordered by increasing priority: operating system environment variables, System.CommandLine env directives, environmentVariables settings in launchSettings.json, and -e|--environment CLI option values.

Using the -e|--environment option enables setting specific environment variables, for example: dotnet run -e ASPNETCORE_ENVIRONMENT=Development, setting environment variables at the highest priority level.

Production Environment Deployment Recommendations

Although the dotnet run command proves highly convenient during development, its usage in production environments is discouraged. This stems from the command resolving application dependencies outside the shared runtime from NuGet cache.

For production environments, recommended practice involves using dotnet publish command to create deployment packages, then deploying the published output content. This approach ensures all dependencies are properly packaged while delivering enhanced performance and reliability.

Implicit Restoration Mechanism

The dotnet run command automatically performs implicit restoration, eliminating the need for manual dotnet restore execution. All commands requiring restoration, including dotnet new, dotnet build, dotnet run, dotnet test, dotnet publish, and dotnet pack, automatically trigger the restoration process.

To disable implicit restoration, employ the --no-restore option. In continuous integration builds or build systems requiring explicit restoration time control, explicit dotnet restore command usage remains available.