.gitignore Builder for .NET / C#

A .gitignore builder for .NET and C# solutions built with Visual Studio or Rider. Tick the sections your project uses — bin/obj output, Visual Studio state, NuGet packages, publish output and test results — and the tool assembles a clean, labelled .gitignore.

Why .NET projects need a careful .gitignore

.NET and C# projects generate a lot of files that should never go into version control, but the generated artifacts are scattered across multiple folders with overlapping patterns. A poor .gitignore either commits build artifacts (causing multi-megabyte diffs and merge conflicts) or ignores too aggressively (accidentally excluding source files that share patterns with outputs). Getting it right from the start saves the team significant pain.

How the patterns work

Each toggle adds a curated block of patterns under a # Header comment. The patterns use several Git-specific techniques:

Case-insensitive matching for MSBuild output. MSBuild can write output to bin, Bin, BIN, Debug, debug, Release, and so on depending on project settings. The patterns use character classes like [Bb]in/ and [Dd]ebug/ to catch all variants without listing every casing explicitly.

Directory-specific trailing slash. Patterns like obj/ (with a trailing slash) match only directories named obj, not files with that name — important because some projects use files like obj.ts.

Negation for wrapper jars. The build output block excludes generated artifacts while preserving source files in the same directory using ! negation patterns.

What each section covers

Build output (bin/ and obj/) — compiled assemblies, intermediate object files, and configuration-specific output (Debug/, Release/, x64/, etc.). These are fully regenerated by MSBuild on every build; committing them causes massive diffs and makes git status noisy.

Visual Studio state (.vs/, *.user, *.suo) — per-developer IDE state: window layout, last-opened files, breakpoint positions, and project-specific settings. These differ between machines and cause irrelevant conflicts.

NuGet packages (packages/) — with modern PackageReference-style projects, NuGet packages are restored automatically on build from *.csproj references. The packages/ folder (used by the older packages.config format) should not be committed. Keep packages.lock.json committed if you use it for reproducible restores.

Publish output (publish/, *.pubxml.user) — the output of dotnet publish and Visual Studio publish profiles, including deployment configuration and credentials. These are derived artifacts that sometimes contain environment-specific secrets.

Test results (TestResults/, *.trx, *.coverage) — test run output files generated by Visual Studio Test Explorer and dotnet test. These are large, binary in some cases, and machine-specific.

Rider IDE (.idea/) — JetBrains Rider’s project-level settings directory. Similar to .vs/, these are per-developer preferences that should stay local.

Patterns you might add manually

For specific project types not covered by the toggles:

# Secrets and local config — never commit
appsettings.Development.json
appsettings.Local.json
*.pfx
*.key

# Azure Functions local settings
local.settings.json

# Docker build context leftovers
*.tar.gz

Tips

• Place the .gitignore at the root of your solution (the folder containing the .sln file) so patterns apply to all projects in the solution.
• If a file is already tracked, a .gitignore entry will not untrack it. Run git rm --cached <file> and commit to stop tracking it.
• Pair with an .editorconfig to enforce consistent formatting and a Directory.Build.props to standardise build settings across all projects in the solution.