dennisdoomen / dennisdoomen/dotnet-library-starter-kit
[Feature]: Pin build tool versions in a dotnet-tools manifest
- Dominant language
- C#
- Stars
- 77
- Forks
- 5
- PR merge metrics
- No merged PRs in 30d
Description
### Background and motivation
The build relies on several .NET tools — GitVersion, ReportGenerator, PackageGuard and InspectCode among them. Some are pulled in through Fallout attributes with a version, others are resolved at build time. There is no single place that records which tool versions a build uses.
A `.config/dotnet-tools.json` manifest pins every tool in one file, lets a contributor run `dotnet tool restore` to get exactly what CI has, and gives Dependabot a file it can keep updated.
Proposal: add a tool manifest to the templates and use it as the source of truth for tool versions.
### Alternative Concerns
* Fallout resolves several of these tools itself through `[NuGetPackage]` attributes, so a manifest could end up as a second, competing source of versions. It is worth checking what Fallout supports before doing this, so the two do not disagree.
* If Fallout's own resolution is already deterministic and pinned, this may add little beyond discoverability.
### Could you help with a pull-request?
No
Contributor guide
Research direction
Start by inspecting the templates and the existing Fallout [NuGetPackage] attributes that resolve GitVersion, ReportGenerator, PackageGuard, and InspectCode. Check whether Fallout already pins these tools before deciding how .config/dotnet-tools.json would become the single source of truth. Done means the manifest records the required versions, contributors can restore them, and the build has no conflicting version sources.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- csharp
- Domain
- build-system, tooling
- Issue type
- Feature
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 56/100