BuildCheck NET 10.0 investments

[JanKrivanek]

Context

In net 9.0 we delivered initial preview of BuildCheck feature.

• Spec: https://github.com/dotnet/msbuild/blob/main/documentation/specs/BuildCheck/BuildCheck.md
• Work track: https://github.com/orgs/dotnet/projects/373

This item captures high level thinking of continuation of that work in net 10.0 - which will aim for increased adoption and improved usability based on the collected feedback and data.

Priority bugs

• [x] https://github.com/dotnet/msbuild/issues/11209

Suggested areas of investments

Based on team discussion and voting we came up with following areas (in aproxiate priority order):

• [ ] Dogfooding (P'0')
  • idea: use VS feature flagging to test run BuildChecks on subset of users (even just internals) + this can be used to get perf data
  • [ ] https://github.com/dotnet/msbuild/issues/10726
• [ ] Telemetry / data collection (usage, performance and failures data collection)
  • [x] https://github.com/dotnet/msbuild/issues/10634
• [ ] UX investments (p1)
  • UX for users [ ] https://github.com/dotnet/msbuild/issues/10727
    • VS and VS Code usability and opt-in
    • CLI and VS diagnostics usability (unifying the experience with native diagnostics)
  • UX for extensibility authors
    • templates, debuggability story
• [ ] Performance (tracing, measurments, tunning; DTB and full (CI) build PoV) (P1)
  • #9829
• [ ] OM and API concepts (P1/P2)
  • scoping, locations
  • versioning (ability to run analyzers compiled against older V of API to be runnable in newer MSBuild)
• [ ] Built-in Rules - should be reactive on community reactions
  • + continuation of https://github.com/dotnet/msbuild/issues/9630:
    • [x] #9880
    • [x] #9882
    • [ ] #9884
    • [x] #9888
    • [ ] #9889
    • [ ] #9891
    • [ ] #9892
  • + Adopt some security check ideas:
    • [x] Untrusted loacation check
    • [ ] Common targets (or any) task overwriten
    • [ ] Imports from unexpected locations
• [ ] OM and API enriching - should be reactive mode
  • exposing of additional engine data
• [ ] Configuration V2 (P3)
  • guidelinces + guardrails
  • support for native msbuild diagnostics
  • unification with Roslyn parser?
• [ ] Localization (priority: ?)
  • here we should ask Roslyn team what was their timeline on localization
  • MSFT policy is that products should be localized
  • inbox checks localization is a P1
  • for extensibility we can take some inspiration from Tasks localization

[JanKrivanek]

Another area:

• [ ] Replay improvements.
  • ability to mount new custom checks to the replay
  • ability to specify custom editorconfig to tune the level of checking

This can possibly be considered a subitem of the UX for extensibility authors

[Nirmal4G]

Allow BuildChecks to be published to and consumed from an SDK (on disk/NuGet) package.

[KalleOlaviNiemitalo]

Allow BuildChecks to be published to and consumed from an SDK (on disk/NuGet) package.

Doesn't that work already, by invoking the [MSBuild]::RegisterBuildCheck function from a props file in the package? See Microsoft.Build.Templates and the documentation that was added in https://github.com/dotnet/msbuild/pull/11053.

[Nirmal4G]

Not a fan of [MSBuild]::RegisterBuildCheck intrinsic function. I expected it to be provided with syntax similar to UsingTask!

For Example:

	<UsingBuildCheck Assembly="$(BuildCheckTasksAssembly)" />
	<UsingBuildCheck Name="Check1" Assembly="$(BuildCheckTasksAssembly)" />

[KalleOlaviNiemitalo]

In the UsingBuildCheck syntax, if a package wanted to provide a BuildCheck for newer versions of MSBuild but remain compatible with older versions too, I suppose the UsingBuildCheck element would have to be placed in a separate, conditionally-imported file.