Ship TaskAnalyzer as a separate package with safe defaults

[VolPlita]

This PR ships the TaskAnalyzer as a separate Microsoft.Build.TaskAuthoring.Analyzer package and declares the dependency from Microsoft.Build.Framework for build-time analyzer consumption. This keeps analyzer updates independent from MSBuild API versioning while preserving compatibility for older hosts.

Scope:

• ship the analyzer as a separate package
• keep the default task-authoring diagnostics safe and non-breaking for regular tasks
• require opt-in migration configuration for broader MT-style analysis
• update package metadata and docs to match the shipped package model

Fixes #15035

[Copilot]

🟡 Changes recommended

Critical package-consumption validation and related documentation and release-tracking updates remain unresolved.

Get a fresh assessment by requesting another Copilot review.

Pull request overview

This PR packages TaskAnalyzer with Microsoft.Build.Framework under analyzers/dotnet/cs and enables its shipping configuration.

Changes:

• Adds the analyzer to the Framework package.
• Enables shipping configuration.
• Updates TaskAnalyzer delivery documentation.

File summaries

File	Review result
src/TaskAnalyzer/TaskAnalyzer.csproj	Enables shipping configuration. Nit (2 votes): release tracking still marks all rules unshipped.
src/TaskAnalyzer/README.md	Nit (3 votes): documentation conflicts with the bundled-package model and should distinguish direct references.
src/Framework/Microsoft.Build.Framework.csproj	Critical (3 votes): lacks package-consumption validation. Nit (1 vote): the Framework package README does not document the bundled analyzer.

Review details

Suppressed comments (2)

src/Framework/Microsoft.Build.Framework.csproj:105

• The package README is src/Framework/README.md (Directory.Build.targets sets PackageReadmeFile to README.md), but this change only updates TaskAnalyzer/README.md. A consumer installing Microsoft.Build.Framework therefore gets no documentation of the analyzer, its default MT-only scope, migration option, suppression, or warnings-as-errors behavior. Add this guidance to the Framework package README or link to packaged documentation.

    <!-- Ship the TaskAnalyzer alongside the framework package so consumers receive it without a direct analyzer package reference. -->
    <None Include="$(ArtifactsBinDir)TaskAnalyzer\$(Configuration)\netstandard2.0\Microsoft.Build.TaskAuthoring.Analyzer.dll"
          Pack="true"
          PackagePath="analyzers\dotnet\cs\Microsoft.Build.TaskAuthoring.Analyzer.dll" />

src/Framework/Microsoft.Build.Framework.csproj:105

• Placing this DLL under analyzers/dotnet/cs makes every existing Microsoft.Build.Framework PackageReference activate diagnostics automatically. The analyzer has warning rules that apply to regular tasks (MSBuildTask0004 and transitive MSBuildTask0005), while the WarningsNotAsErrors exception exists only in the in-repo Tasks project; existing consumer builds using TreatWarningsAsErrors can therefore start failing on a Framework package update. This needs an explicit opt-out/ChangeWave or another opt-in activation path, plus an opt-out test, before shipping.

    <None Include="$(ArtifactsBinDir)TaskAnalyzer\$(Configuration)\netstandard2.0\Microsoft.Build.TaskAuthoring.Analyzer.dll"
          Pack="true"
          PackagePath="analyzers\dotnet\cs\Microsoft.Build.TaskAuthoring.Analyzer.dll" />

• Files reviewed: 3/3 changed files
• Comments generated: 3
• Review effort level: Lite

[baronfel]

I do not think we want to ship the analyzers directly with Microsoft.Build.Framework - this prevents folks that are using older versions of the MSBuild APIs (i.e. for compatibility with older MSBuild hosts) from using newer versions of the analyzers, which still might find useful issues for them to solve.