Add CsWinRTMarshallingMode option for non-Windows TFM marshalling

[Sergio0694]

Summary

Add a new CsWinRTMarshallingMode MSBuild option (default minimal) that lets the interop generator (cswinrtinteropgen) analyze assemblies that don't target a -windows TFM (i.e. don't reference any CsWinRT assembly) when discovering user-defined/CCW types and generic instantiations. Also add a CsWinRTMarshallingEnabledAssembly item for opting in specific assemblies regardless of the mode.

Motivation

Today, the interop generator only harvests marshalling info from .dlls that reference the Windows Runtime assembly (i.e. those built targeting a -windows TFM). This forces developers to put any type that needs to be marshalled to native (e.g. MVVM viewmodels implementing WinRT interfaces) into a -windows project, even when that project conceptually shouldn't target Windows at all and doesn't use any Windows API. Ideally, a project with just viewmodels should be able to target plain .NET.

This change removes that restriction: by default, the generator now analyzes all (non-BCL) assemblies for user-defined/CCW/generic types, regardless of their TFM, so marshalling those types just works without forcing a -windows TFM.

Behavior and modes

CsWinRTMarshallingMode supports three modes:

• all: analyze all assemblies, including those from the .NET base class library (BCL).
• minimal (default): same as all, but skip assemblies from the .NET base class library (BCL) to reduce binary size.
• strict: only analyze assemblies referencing the Windows Runtime assembly (i.e. those targeting a -windows TFM). This is the previous behavior.

Assemblies that reference the Windows Runtime assembly are always analyzed, regardless of the mode. Assemblies targeting a legacy/portable runtime (.NET Standard or .NET Framework) are never analyzed (see below). BCL/framework assemblies are identified by their well-known Microsoft public key tokens.

Opting in specific assemblies

The CsWinRTMarshallingEnabledAssembly item forces the generator to analyze specific assemblies regardless of the mode. This enables fine-tuning binary size — e.g. keeping strict mode while opting in a few assemblies known to be needed, without switching to minimal (which increases binary size more):

<PropertyGroup>
  <CsWinRTMarshallingMode>strict</CsWinRTMarshallingMode>
</PropertyGroup>
<ItemGroup>
  <CsWinRTMarshallingEnabledAssembly Include="MyApp.ViewModels" />
</ItemGroup>

Three diagnostics validate the opt-in entries:

• CSWINRTINTEROPGEN0098 (warning): an entry doesn't match any referenced assembly.
• CSWINRTINTEROPGEN0099 (message): an entry already targets Windows, so it's redundant.
• CSWINRTINTEROPGEN0100 (message): the mode is all, so all entries are redundant.

Skipping legacy-runtime assemblies (fixes a regression from the new default)

Defaulting to minimal means the generator now analyzes third-party libraries that target .NET Standard / .NET Framework (e.g. Roslyn and BenchmarkDotNet, referenced by SourceGenerator2Test and Benchmarks). The entire interop generator infrastructure identifies well-known types — including custom-mapped types such as IEnumerable<T> — by comparing against type references scoped to the modern .NET corlib (e.g. System.Runtime), which the emit phase also uses. Legacy-runtime assemblies declare those same types against a different corlib (netstandard/mscorlib), which AsmResolver's SignatureComparer treats as a distinct scope — so the generator can't match them, and generating marshalling code for them failed with CSWINRTINTEROPGEN0055/0020. Such assemblies could in principle still use custom-mapped types that need marshalling, but for simplicity they're now skipped during discovery via a new ModuleDefinition.TargetsLegacyRuntime check.

Changes

• src/WinRT.Generator.Core/: add case-insensitive, name-based parsing/serialization of enum-typed response file arguments; BaseClassLibraryIdentity (identify BCL assemblies by public key token); and the shared WellKnownGeneratorMessage type (informational build messages, logged through the ConsoleAppFramework logger).
• src/WinRT.Interop.Generator/: add the CsWinRTMarshallingMode enum + --marshalling-mode argument (default Minimal), the --marshalling-enabled-assembly-names opt-in argument and its diagnostics, the IsBaseClassLibraryModule / TargetsLegacyRuntime module helpers, and the ShouldProcessModule / ValidateMarshallingEnabledAssemblies discovery logic.
• src/WinRT.Generator.Tasks/RunCsWinRTInteropGenerator.cs: add the MarshallingMode and MarshallingEnabledAssemblies task parameters, with validation and response-file emission.
• nuget/Microsoft.Windows.CsWinRT.CsWinRTGen.targets: add the CsWinRTMarshallingMode property (default minimal) and the CsWinRTMarshallingEnabledAssembly item, plumbed to the task and the generator's property-inputs cache hash.
• docs/usage.md, nuget/readme.md, .github/skills/interop-generator/SKILL.md, .github/copilot-instructions.md: document the new options, diagnostics, and behavior.

Testing

All affected tooling projects build clean in Release (warnings-as-errors, 0 warnings). The full argument pipeline (item → task → response file → parser → discovery) was validated end-to-end against the built cswinrtinteropgen. The corlib-scope root cause and the TargetsLegacyRuntime fix were validated against real net10.0 (System.Runtime) and .NET Standard 2.0 (netstandard) assemblies.