Starting a new .NET project is exciting, but it can also be overwhelming. There are so many decisions to make, and the choices you make in the first few days will affect your project for months or even years.
I have created dozens of .NET projects over the years, and today I want to share my experience with you.
In this post, we will explore the following essential steps to start a new .NET project:
- Set Project-Wide Standards
- Add Static Code Analysis Packages
- Enforce Coding Standards
- Centralize Package Management
- Simplify Local Development with Aspire
- Setup OpenTelemetry
- Automate Build and Testing with GitHub Actions
- Project Template to Start With
Let's dive in.
1. Directory.Build.props - Set Project-Wide Standards
Every .NET solution should start with a Directory.Build.props file. This file defines project-wide settings that apply to all projects in your solution.
Without this file, you end up duplicating the same configuration across multiple .csproj files. When you want to change a setting, you have to update every project file manually. This leads to inconsistencies and wasted time.
Directory.Build.props solves this problem by centralizing configuration in one place. You create this file in the same directory as your .sln file, and MSBuild automatically applies it to all projects in the solution.
Here is the configuration I use for every new project:
<Project>
<PropertyGroup>
<Nullable>enable</Nullable>
<ImplicitUsings>enable</ImplicitUsings>
<AnalysisLevel>latest</AnalysisLevel>
<AnalysisMode>All</AnalysisMode>
<TreatWarningsAsErrors>true</TreatWarningsAsErrors>
<CodeAnalysisTreatWarningsAsErrors>true</CodeAnalysisTreatWarningsAsErrors>
<EnforceCodeStyleInBuild>true</EnforceCodeStyleInBuild>
</PropertyGroup>
</Project>
If needed, you can also put Directory.Build.props on any directory level in your project hierarchy and override settings there.
Here is what each setting does:
Nullable: Enables nullable reference types, which help prevent null reference exceptions. The compiler warns you when you might be using a null value incorrectly.
ImplicitUsings: Automatically includes common namespace imports in every file. You do not need to write using System; or using System.Linq; anymore.
AnalysisLevel: Sets the code analysis level to the latest version. You get the most recent code quality checks from Microsoft.
AnalysisMode: Enables all code analysis rules. This gives you the most comprehensive feedback on code quality.
TreatWarningsAsErrors: Prevents compilation if there are any warnings. This forces you to fix issues immediately rather than letting them accumulate.
CodeAnalysisTreatWarningsAsErrors: Applies the same strict treatment to code analysis warnings.
EnforceCodeStyleInBuild: Runs code style checks during build, not just in the IDE. Your CI/CD pipeline will catch style violations.
These settings create a strong foundation for code quality. They catch issues early and enforce consistency across your entire solution.
👉 Read the full article on my newsletter: https://antondevtips.com/blog/how-to-start-a-new-dotnet-project-in-2026
Top comments (1)
I particularly appreciate the emphasis on setting project-wide standards using the Directory.Build.props file, as seen in the example configuration you provided, which enables features like nullable reference types and implicit usings. In my experience, centralizing configuration in this way has been a huge time-saver when working on large .NET solutions, as it eliminates the need to duplicate settings across multiple projects. I'm curious to know if you've explored using custom MSBuild tasks or targets to further automate and streamline the build process, and if so, how you've integrated them into your workflow.