Do not treat Windows Runtime attribute types as Windows Runtime types

[Sergio0694]

Problem

Using a projected Windows Runtime attribute type as a generic type argument failed the whole build:

error CSWINRTINTEROPGEN0055: Failed to generate the type signature for type 'TestComponentCSharp.MyStringAttribute'.

type.GetCustomAttributes<SomeAttribute>() is enough to trigger it — it creates IEnumerable<SomeAttribute> and IEnumerator<SomeAttribute> instantiations in the assembly.

Root cause

Windows Runtime attributes are metadata-only: they are never activated and never cross the ABI boundary, so the projection deliberately emits no marshalling infrastructure for them — no default interface, no IID, no Impl type, no marshaller (everything in ProjectionGenerator.Namespace.cs is guarded on !type.IsAttributeType).

It did however still stamp them with [WindowsRuntimeType], which is precisely the statement "this type participates in Windows Runtime marshalling". Both consumers believed it and then failed to find any marshalling logic:

• Interop generator. IsWindowsRuntimeType classifies a generic instantiation as a Windows Runtime one only when every type argument is a Windows Runtime type. That is why IEnumerable<SomeManagedClass> is not one, is never tracked, and the CCW instead gets IEnumerable<object> from the covariance expansion. Attribute types wrongly passed that check, so IEnumerable<SomeAttribute> went down the Windows Runtime path and SignatureGenerator.Class found neither a default interface nor an IID → CSWINRTINTEROPGEN0055.
• Runtime. WindowsRuntimeMarshallingInfo.GetMetadataProviderType short-circuits on [WindowsRuntimeType] for non-generic types and returns the type as its own metadata provider. GetOrCreateComInterfaceForObject then calls GetComWrappersMarshaller(), which throws NotSupportedException instead of falling through to the opaque-IInspectable path that every other managed object takes.

One cause, two symptoms — the second only became reachable once the first was worked around.

Fix

Stop reporting attribute types as Windows Runtime types.

• Projection writer — don't emit [WindowsRuntimeType] on attribute types. The .winmd stem is still recorded in the centralized ABI.WindowsRuntimeMetadataTypes lookup, since that is build-time only data for the other generators.
• Interop generator — exclude them in IsWindowsRuntimeType / IsNotExclusiveToWindowsRuntimeType. This is still needed on top of the above, because reference projections carry no per-type marker at all: IsReferenceProjectionWindowsRuntimeType is assembly-level, so every type in a NuGet-shipped reference projection would otherwise still qualify.

Attribute types now behave like any managed type: List<SomeAttribute> is handled exactly like List<SomeManagedClass> — it still gets its own proxy/type-map entry, its CCW gets IIterable<IInspectable> from the covariance expansion, and the attribute instances marshal as opaque IInspectable objects.

The detection is a direct base-type comparison against System.Attribute. Windows Runtime attributes always derive directly from it (the type system does not allow an attribute to derive from another one), so no base-class-chain walk is needed.

Notes

An earlier revision of this PR type-erased the attribute type arguments to object in the interop generator instead. That treated the symptom rather than the cause: it needed a dedicated eraser, erasure call sites in three discovery entry points, careful ordering against the resolvability guards, and an extra parameter threaded through TryAddExposedInterfaceType for the dedup invariant — and it still left the runtime failure in place. All of that is gone; the existing managed/covariance path already does the right thing once the classification is correct.

It also removes the IsAssignableFrom call that was tripping the NullReferenceException reported in Washi1337/AsmResolver#770.

Tests

Two tests in src/Tests/UnitTest:

• TestGenericsOverWindowsRuntimeAttributeTypes — the original repro (GetCustomAttributes<T>), then marshals a List<SomeAttribute> across the ABI through an IIterable<Object> property and round-trips it back. The test building covers the CSWINRTINTEROPGEN0055 failure; the assertions cover the GetComWrappersMarshaller one, since the native side enumerates the collection and marshals the attribute instances.
• TestWindowsRuntimeAttributeTypeInterfaceEntriesAreNotDuplicated — reads the CCW's IIDs via IInspectable::GetIids and asserts IIterable<IInspectable> appears exactly once (a duplicate entry is invisible to QueryInterface, so this is the only way to observe it).

Validation

• All five build tools build clean.
• Full CsWinRT pipeline (projection ref gen → SDK/merged projection gen → impl gen → interop gen) verified end-to-end on ObjectLifetimeTests.Lifted.
• Regenerated the TestComponentCSharp implementation projection and confirmed MyStringAttribute no longer carries [WindowsRuntimeType], that real runtime classes such as NonAgileClass still carry it plus their marshaller, and that the .winmd stem entry is still emitted.

[azure-pipelines]

Azure Pipelines:
There may be pipelines that require an authorized user to comment /azp run to run.

[azure-pipelines]

Azure Pipelines:
There may be pipelines that require an authorized user to comment /azp run to run.