Fallout-build / Fallout-build/Fallout
Expose a typed PackageId accessor on Project
- Dominant language
- C#
- Stars
- 154
- Forks
- 19
- Avg merge
- 1d 22h
- Merged PRs (30d)
- 15
Description
### Problem
`build/Build.cs` reads the global tool's id with a stringly-typed MSBuild lookup:
```csharp
var packageId = Solution.Fallout_Cli.GetProperty("PackageId");
```
`ProjectExtensions` already has typed accessors for the well-known properties a build actually reaches for — `GetTargetFrameworks()`, `GetRuntimeIdentifiers()`, `GetOutputType()`, `HasPackageReference()`. Package metadata has none, so every consumer that needs `PackageId` hand-writes the property name: no compile-time check, no discoverability, and a typo returns `null` rather than failing.
Raised in review on #581 ("probably deserves a standalone property, but that's a job for another day").
### Outcome
Reading a project's package id is a first-class API on `Project`, in the same shape as the accessors next to it. `build/Build.cs` stops naming an MSBuild property in a string.
### Acceptance criteria
- [ ] `ProjectExtensions` exposes a typed `PackageId` accessor, following the existing `Project.Misc.cs` conventions.
- [ ] Resolution matches MSBuild: an explicit `` wins, otherwise it falls back to `AssemblyName`/`MSBuildProjectName` — a project without an explicit `` still returns the id it would actually pack as.
- [ ] `build/Build.cs`'s `Install` target uses the accessor instead of `GetProperty("PackageId")`.
- [ ] Specs in `tests/Fallout.ProjectModel.Specs` cover both cases — a project with an explicit `` (`Fallout.Cli` → `Fallout.GlobalTool`) and one relying on the fallback.
- [ ] Additive only. `GetProperty` stays as the escape hatch for arbitrary properties.
### Notes
Related to #584 (centralising Fallout's own configuration) but distinct: #584 is about where *our* values live, this is a gap in the public `Fallout.ProjectModel` surface that any consumer build hits.
Contributor guide
Research direction
Start with the typed accessors in Project.Misc.cs and the PackageId lookup in build/Build.cs, then inspect the specs under tests/Fallout.ProjectModel.Specs. Verify explicit PackageId and AssemblyName/MSBuildProjectName fallback cases, and confirm the Install target uses the accessor while GetProperty remains available for arbitrary properties.
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
- Clearly specified
- Newbie friendliness
- 76/100