Declare a MetalamaPlatformRequirement for the packages whose supported platforms are stricter than the framework's

[sharpcrafters-agent]

Summary

#1884 introduces the MetalamaPlatformRequirement item and seeds it for Metalama.Framework alone. The comment
on that issue lists four packages of this repository whose requirement is stricter than the framework's, and
records that adding their contributions in a follow-up issue is the acceptable order:

If the plain check has to ship sooner, the fallback is to implement the target so that it reads
@(MetalamaPlatformRequirement) from the start, seed the item from Metalama.Framework alone, and add the
contributions of the four packages listed above in a follow-up issue. The documentation of the item as a public
contract can then follow in that second issue.

This is that follow-up issue. The mechanism shipped in #1886 and is documented in
metalama/Metalama.Documentation#290.

The packages that should declare a requirement

Package	Why its requirement is stricter
Metalama.Patterns.Wpf	It declares net472;net8.0-windows, which #1876 turns into net472;net10.0-windows. It has no netstandard2.0 asset and it requires the Windows platform, so it is narrower than the framework on two dimensions at once. This is the motivating case, and #1876 records it as a breaking change.
Metalama.LinqPad	It targets net8.0-windows, which becomes net10.0-windows. Its requirement follows the LINQPad host rather than the framework.
Metalama.Extensions.DiffEngine	It already selects assets per target framework through MetalamaExtensionAssembly, so it has a requirement to state and already has the build folder to state it in.
Metalama.Extensions.HtmlWriter	The same.

The Metalama.Patterns.* packages that declare netstandard2.0 beside the .NET target framework have the same
requirement as the framework and should declare nothing. None of them has a build folder today, and none should
gain one for this.

What has to be done

For each of the four packages, add a MetalamaPlatformRequirement item to its build/<PackageId>.props and to
the same file under buildTransitive. Metalama.Patterns.Wpf and Metalama.LinqPad have no build folder yet,
so this issue creates one for them, which is a packaging change and needs its own verification that the props file
reaches the consumer.

The item must be declared in a .props file rather than a .targets file. NuGet imports the build props of
every package before it reads any targets file, so the check sees every contribution whatever the order in which
NuGet imports the packages.

Order with respect to #1876

The values to declare are the target frameworks that #1876 leaves each package with. Doing this issue before
#1876 would declare values that #1876 immediately changes, so this issue should follow #1876.

Acceptance criteria

• A project that targets net10.0 without the Windows platform and references Metalama.Patterns.Wpf reports
  LAMA0600 naming Metalama.Patterns.Wpf.
• A project that targets net10.0-windows and references Metalama.Patterns.Wpf reports nothing.
• MetalamaSupportedPlatformExclusion with Metalama.Patterns.Wpf suppresses that warning and leaves the
  warning of Metalama.Framework, if any, in place.
• Building this repository reports none of these warnings.
• The MetalamaPlatformRequirement item is documented as a public contract that a third-party package may use,
  with the compatibility obligations that Warn when the target framework, the .NET SDK or the Visual Studio version is outside the tested support matrix #1884 records: unknown metadata is ignored, and absent metadata means no
  constraint.

— Claude for Gaël Fraiteur (@gfraiteur)

[gfraiteur]

Closing as not planned. The gap this issue describes is already covered, and covered better, by mechanisms that were not considered when it was written. The packaging of the four packages was checked on develop/2027.0 after #1876 and #1886 merged.

The two motivating packages are covered by NuGet, with a better diagnostic

Metalama.Patterns.Wpf is an ordinary package: it ships lib assets for net472 and net10.0-windows, it has no netstandard2.0 asset, and it has no build folder. A project that targets plain net10.0 therefore resolves no asset at all, and restore fails with NU1202, naming the package and listing the target frameworks it supports. That diagnostic is an error rather than a warning, it names the same package that LAMA0600 would name, and it is reported at restore, which is earlier than the check runs. Metalama.LinqPad, which targets net10.0-windows alone, has the same shape.

The .NET 8 and .NET 9 case that #1876 records as a breaking change is covered by the requirement of Metalama.Framework itself, whose MinimumNETCoreAppVersion is 10.0. A consumer that targets net8.0 reports LAMA0600 whether or not Metalama.Patterns.Wpf declares anything.

What remains is narrower than the issue assumes

Metalama.Extensions.DiffEngine and Metalama.Extensions.HtmlWriter are the only two packages here that cannot produce NU1202. They set IncludeBuildOutput to false, suppress NU5128 and remove every item from BuildOutputInPackage, so they ship no lib folder and only a build folder with assemblies under metalama/net472 and metalama/net10.0. NuGet considers a package of that shape compatible with every target framework.

Their selection is nevertheless sound for the frameworks that matter. Metalama.Testing.AspectTesting.targets filters MetalamaExtensionAssembly with [MSBuild]::IsTargetFrameworkCompatible rather than by string equality, so a net11.0 consumer selects the net10.0 assembly, and a net8.0 or net9.0 consumer is already reported by the requirement of Metalama.Framework.

The only configuration that the framework permits and these two packages do not serve is a consumer that targets netstandard2.0 or netstandard2.1. There the package restores, its props file is imported, no extension assembly matches, and the extension is silently inert. Both packages are plugins of Metalama.Testing.AspectTesting, so that consumer is a test project that targets netstandard2.0, which is not a configuration anyone runs tests in.

The documentation deliverable

The last acceptance criterion, documenting MetalamaPlatformRequirement as a public contract that a third-party package may use, does not depend on these four packages and is worth keeping. This issue records that it is already covered by metalama/Metalama.Documentation#290. If that document does not state the compatibility obligations that #1884 records, that unknown metadata is ignored and that absent metadata means no constraint, then a documentation issue is the right place for it rather than this one.

Reopen if

A package of this repository ships without a lib folder and with a build folder, and its MetalamaExtensionAssembly items do not cover a target framework that the requirement of Metalama.Framework admits. That is the shape that fails silently, and it is worth a declared requirement when it occurs.

[gfraiteur]

Released in 2027.0.1-preview.

— Claude for Gaël Fraiteur (@gfraiteur)