Setting Up a .NET Console App in C#

Verifying the .NET SDK Installation

To create and run a modern C# console app from the command line, you need the .NET SDK (not just the runtime). The SDK includes the compiler, templates, and the dotnet CLI commands used to create, build, and run projects.

Check that the SDK is installed

Open a terminal (Windows Terminal, PowerShell, Command Prompt, or a macOS/Linux shell) and run:

dotnet --version

If the command prints a version number (for example, 8.0.1xx), the SDK is available. If you see an error like “command not found” or “dotnet is not recognized”, install the .NET SDK and ensure your PATH environment variable includes the dotnet install location.

See which SDKs are available (optional)

If you have multiple SDK versions installed, list them:

dotnet --list-sdks

This helps when you need to confirm which SDK will be used on your machine.

Continue in our app.

You can listen to the audiobook with the screen off, receive a free certificate for this course, and also have access to 5,000 other free online courses.

Or continue reading below...

Download the app

Creating a Project with dotnet new console

The .NET CLI can generate a ready-to-run console project using templates. You typically create a new folder for your app, then run the template command inside it.

Step-by-step: create the project

• Create and move into a new folder:

# Windows (PowerShell) or macOS/Linux shell syntax shown generically: create a folder and enter itmkdir HelloConsolecd HelloConsole

• Create a console app project in the current folder:

dotnet new console

This generates a minimal project with a project file and a Program entry point. It also restores any required dependencies automatically (you may see “Restored …” output).

Optional: name the project explicitly

If you want the folder and project name created for you, run this from a parent directory:

dotnet new console -n HelloConsole

This creates a HelloConsole folder containing the project.

Exploring the Generated Files

A console project created by the template is intentionally small. Understanding the purpose of each generated file makes it easier to troubleshoot builds and customize settings.

The project file (.csproj)

In the project folder, you’ll see a file like HelloConsole.csproj. This is the project definition used by the build system. Open it in a text editor to inspect it.

<Project Sdk="Microsoft.NET.Sdk">  <PropertyGroup>    <OutputType>Exe</OutputType>    <TargetFramework>net8.0</TargetFramework>    <ImplicitUsings>enable</ImplicitUsings>    <Nullable>enable</Nullable>  </PropertyGroup></Project>

• OutputType set to Exe means the build produces a runnable console application.
• TargetFramework indicates which .NET version the app targets (for example, net8.0).
• ImplicitUsings can automatically include common namespaces so you write fewer using statements.
• Nullable enables nullable reference type analysis, which can produce helpful warnings.

You usually don’t need to edit the project file for simple console apps, but it’s the central place for configuration when you do.

The entry point (Program.cs)

The template generates Program.cs, which contains the code that runs when the app starts. In modern C#, the template often uses top-level statements (no explicit Main method required).

Console.WriteLine("Hello, World!");

This is a complete program. When you run the project, this line executes and prints text to the console.

Running the App with dotnet run

To compile and run the app in one step, use dotnet run from the project folder (the folder containing the .csproj).

dotnet run

What happens when you run it:

• The project is built (compiled) if needed.
• The resulting executable is launched.
• You see the output in the terminal (for example, Hello, World!).

Understanding build configurations (practical view)

By default, dotnet run uses the Debug configuration. Debug builds are optimized for development (faster iteration, more debugging support). You can run a Release build like this:

dotnet run -c Release

This is useful when you want behavior closer to what you’d ship (more optimizations, different output folder).

Understanding the Build Output Folder

When you build or run a .NET project, the compiled results are placed under the bin folder. You’ll also see an obj folder, which contains intermediate build artifacts.

Where the compiled app goes

After running dotnet run (Debug), look for:

bin/Debug/<target-framework>/

Example for a project targeting .NET 8:

bin/Debug/net8.0/

Inside that folder you’ll typically find:

• The app executable (platform-dependent): on Windows, an .exe may appear; on macOS/Linux you’ll see a runnable host plus supporting files.
• A .dll for your app (your compiled IL code).
• A .deps.json file describing dependencies.
• A .runtimeconfig.json file describing the runtime settings.

In practical terms: if you want to see what your build produced, or verify whether you’re running Debug vs Release, check the bin path and the configuration folder name.

What the obj folder is for

The obj folder contains intermediate files used during compilation (generated assets, temporary build outputs, caches). You generally don’t edit anything in obj. If you ever suspect build artifacts are stale, you can clean them with:

dotnet clean

Or remove bin and obj folders and rebuild (the build will regenerate them).

Exercise: Edit Output Text, Run Again, and Observe Compilation Feedback

This short exercise helps you practice the edit-build-run loop and see how the compiler responds to changes.

Part 1: Change the output and run

• Open Program.cs.
• Change the message:

Console.WriteLine("Hello from my console app!");

• Run the app again:

dotnet run

Observe that the new text appears. The CLI will rebuild only what’s necessary, then run the updated output.

Part 2: Trigger a compiler error and read it

Now intentionally introduce a small error so you can see what compilation feedback looks like.

• Edit Program.cs to remove the semicolon:

Console.WriteLine("This will fail")

• Run:

dotnet run

You should see a build failure with an error message that includes:

• The file name (Program.cs)
• A line number and column
• An error code (for example, CS1002)
• A short description (for example, “; expected”)

Fix the issue by restoring the semicolon, then run again to confirm the build succeeds.

Part 3: Observe warnings (optional)

Warnings don’t stop the build, but they indicate potential issues. For example, you can create an unused variable:

var message = "Unused";Console.WriteLine("Running with a warning example");

Run the project and look for warning output. This helps you get used to reading compiler feedback and keeping builds clean.