A small app can grow into a solution
A project is the unit that .NET builds into an application or library. It brings source files, settings and dependencies together. A solution is an optional way to group related projects, such as a console application and a reusable library. You can start with one project and add a solution when more projects make that useful.
The examples below use the .NET 10 SDK and its modern C# console template. Older SDKs may generate a different solution-file format, but the roles of the files are the same.
.cs files hold your C# code
Program.cs is the source file that contains the first console program. The .cs extension identifies C# source. You can add more .cs files for classes or other code as the app grows. In a normal SDK-style project, C# files under the project folder are included for compilation automatically, so you usually do not list every source file in the project file.
A source file is not an executable by itself in this project workflow. The SDK compiles its code with the rest of the project. Put related code in clearly named files, such as Order.cs for an Order class, and keep generated bin and obj files separate from code you edit.
Program.cs — editable source
Console.WriteLine("Hello, Codectionary!");The .csproj file describes one project
A C# project file ends in .csproj and uses XML. The example below is a small, illustrative SDK-style console project targeting .NET 10; the file generated on your machine may have additional settings. Sdk selects the build tools, OutputType Exe requests a runnable application, and TargetFramework net10.0 selects the .NET APIs and runtime target. ImplicitUsings and Nullable are compiler conveniences; you can learn them later.
The target framework is a project setting, not the installed SDK version. A suitable SDK builds the project, while a compatible runtime is needed to run a framework-dependent output. Change the target only after checking the APIs and platforms your app needs. Package and project references also live in this project file; do not mistake it for the solution file.
HelloApp.csproj — illustrative .NET 10 console project
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<OutputType>Exe</OutputType>
<TargetFramework>net10.0</TargetFramework>
<ImplicitUsings>enable</ImplicitUsings>
<Nullable>enable</Nullable>
</PropertyGroup>
</Project>A solution groups projects
A solution file lists the projects you want to open or build together. Current .NET 10 dotnet new sln creates an .slnx solution; .NET 9 and earlier create the older .sln format by default. Existing .sln files still matter, so follow the format present in your project instead of renaming a file to change formats. Neither .sln nor .slnx contains your C# program.
The commands below create one console project and add it to a new .NET 10 solution. Run them in a writable parent folder with a .NET 10 SDK installed. The final command builds the solution; for a lone project, you can simply build its .csproj. A solution is useful when an app later has several cooperating projects.
Terminal — one project in a .NET 10 solution
dotnet new console -n HelloApp
dotnet new sln -n Learning
dotnet sln Learning.slnx add HelloApp/HelloApp.csproj
dotnet build Learning.slnxDebug and Release builds
A build configuration is a named set of build settings. Debug is the default for most projects and is convenient while developing and debugging. Release commonly enables optimisation for distribution. Neither name changes your source language, and publishing or deploying an app is a separate step. A project can customise what each configuration means.
From the parent folder in the example, specify the project path to avoid ambiguity. Both commands compile the same source, but produce output in configuration-specific locations under bin. Build output and temporary files under bin and obj are generated; edit the .cs and .csproj files instead.
Terminal — build the project in two configurations
dotnet build HelloApp/HelloApp.csproj --configuration Debug
dotnet build HelloApp/HelloApp.csproj --configuration ReleaseHow projects depend on other code
A project can use code from another project through a project reference. For example, an app might reference a Shared library in the same solution. The app depends on Shared: the build tools compile the required project and make its public code available to the app. Adding both projects to a solution alone does not create this dependency.
A project can also depend on a published NuGet package. That is a package reference, not a project reference. The two are written differently in the .csproj file, and NuGet restores packages before the build. Beginners can start with the libraries supplied by .NET and add a dependency only when it solves a real need.
Conceptual .csproj references — paths and packages must exist
<ItemGroup>
<ProjectReference Include="../Shared/Shared.csproj" />
<PackageReference Include="Newtonsoft.Json" Version="13.0.4" />
</ItemGroup>Keep a small project easy to navigate
A first project needs only its .csproj and Program.cs. Add folders and files as responsibilities become clear: for example, Models/Order.cs for data and Services/PriceCalculator.cs for calculation. Names should tell a reader where to find a concept. Do not create a deep hierarchy for a ten-line exercise.
The solution file belongs near the projects it groups. Keep source and configuration files in version control, but usually leave generated bin and obj output out. When another developer opens the project, restore its declared packages and build it; do not copy your local build folders as the project source.
Syntax
dotnet build --configuration DebugExamples
A minimal SDK-style C# project file
This XML tells the .NET 10 SDK to build a runnable C# project.
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<OutputType>Exe</OutputType>
<TargetFramework>net10.0</TargetFramework>
<ImplicitUsings>enable</ImplicitUsings>
</PropertyGroup>
</Project>- Save this as a .csproj in a project folder that also contains Program.cs. The SDK reads the project file when you run dotnet build in that folder.
- Microsoft.NET.Sdk supplies the standard build behavior. Exe asks for a runnable output; net10.0 selects the target framework and available APIs.
- The SDK includes ordinary .cs files in this folder automatically. ImplicitUsings makes common namespaces such as System available to the simple Console.WriteLine example; without it you can write using System; in Program.cs. The project file records build choices; the source file contains the statements your program executes.
Best practices
- Start with one project; add a solution when multiple projects need to be managed together.
- Inspect TargetFramework before changing SDKs or copying commands from another project.
- Use Debug for development and Release when its settings suit your distribution workflow.
- Do not edit or commit generated bin and obj output as source.
Runtime & versions
.NET runtime. Feature availability depends on the language and runtime version used by your project; consult the official reference below.
C# language reference