Spun off from the JetBrains.Annotations removal PR.
That PR dropped the JetBrains.Annotations library dependency. This issue covers the CLI tool that remains:
- `build/_build.csproj` has `` so the InspectCode tool is available locally during this repo's build.
- This repo's `Build` class implements `IReportIssues` (and `IReportDuplicates`), components that run InspectCode against the solution to surface static analysis findings.
- The framework also ships a `Fallout.Common.Tools.ReSharper` tool wrapper that lets any consumer's build invoke InspectCode the same way.
Two semi-independent questions
-
Does this repo's own build keep running InspectCode? Even if we don't use JetBrains as a library, the CLI tool is still useful for finding code smells if you're willing to invoke a JetBrains binary as part of your build. Removing it: drop the `PackageDownload`, drop `IReportIssues`/`IReportDuplicates` from `Build`'s implements list, drop the `InspectCode`-flavored release behavior.
-
Does Fallout keep shipping the ReSharper tool wrapper? Independently, we could keep the `Fallout.Common.Tools.ReSharper` JSON spec + `Generated.cs` so consumers who do want InspectCode in their build have a typed wrapper for it. Or drop the wrapper too (lose the convenience; consumers can still shell out).
Options
|
Repo build |
Tool wrapper |
Tradeoff |
| A |
Drop |
Drop |
Cleanest JetBrains-free story. No InspectCode anywhere. |
| B |
Drop |
Keep |
Repo doesn't pay for it, consumers can opt in. |
| C |
Keep |
Keep |
Status quo minus the library annotations. |
I'd nudge toward B if you want to leave the door open for consumers, A if you want a clean break.
Done when
Spun off from the JetBrains.Annotations removal PR.
That PR dropped the JetBrains.Annotations library dependency. This issue covers the CLI tool that remains:
Two semi-independent questions
Does this repo's own build keep running InspectCode? Even if we don't use JetBrains as a library, the CLI tool is still useful for finding code smells if you're willing to invoke a JetBrains binary as part of your build. Removing it: drop the `PackageDownload`, drop `IReportIssues`/`IReportDuplicates` from `Build`'s implements list, drop the `InspectCode`-flavored release behavior.
Does Fallout keep shipping the ReSharper tool wrapper? Independently, we could keep the `Fallout.Common.Tools.ReSharper` JSON spec + `Generated.cs` so consumers who do want InspectCode in their build have a typed wrapper for it. Or drop the wrapper too (lose the convenience; consumers can still shell out).
Options
I'd nudge toward B if you want to leave the door open for consumers, A if you want a clean break.
Done when
JetBrains.ReSharper.GlobalToolsPackageDownload, removeIReportIssues/IReportDuplicatesfromBuild(and decide whether to delete the components fromFallout.Componentstoo)src/Fallout.Common/Tools/ReSharper/, the matching test/Verify snapshots, the TeamCityReSharperInspectCodeimport type