Custom Attribute blob syntax for System.Type is unclear

[nike4613]

Specifically:

ECMA-335 § II.23.3

• If the parameter kind is System.Type, (also, the middle line in above diagram) its is stored as a SerString (as defined in the previous paragraph), representing its name. The canonical name is its full type name, followed optionally by assembly where it is defined, its version, culture and public-key-token. If the name is omitted, the CLI looks first in the current assembly, and then in the system library (mscorlib); in these two special cases, it is permitted to omit the name, version, culture and public-key-token.

(emphasis mine)

The spec calls out mscorlib here, which was reasonable for .NET Framework. However, in .NET Core and .NET Standard, the corelib is no longer in mscorlib, but rather (in the API contract) System.Runtime or netstandard primarily. CoreCLR does not use any of these, however, and instead uses System.Private.CoreLib as the fallback, despite that being a (supposedly) private implementation detail. This is most notably a problem for System.Uri: it is in the reference corelib (System.Uri) on .NET Core and .NET Standard, but its implementation is in System.Private.Uri, not System.Private.CoreLib, so a CA blob that contains System.Uri will fail to resolve!

More detail on where this was found:

Washi1337/AsmResolver#648

@Windows10CE:

For some additional references for behavior being changed by this PR, all checked 2025-06-12:

ECMA-335 6th Edition, Section II.23.3, bottom of page 268, describes how to do resolution when no assembly spec is given for Type arguments: https://ecma-international.org/wp-content/uploads/ECMA-335_6th_edition_june_2012.pdf

The current behavior of CoreCLR, which attempts current assembly, then typeof(object).Assembly (System.Private.CoreLib), then the TypeResolve event of the current AssemblyLoadContext:

runtime/src/coreclr/System.Private.CoreLib/src/System/Reflection/TypeNameResolver.CoreCLR.cs

Line 344 in b49ebac

private Type? GetTypeFromDefaultAssemblies(string typeName, ReadOnlySpan<string> nestedTypeNames, TypeName parsedName)

The current behavior of Roslyn (the C#/VB compiler), which always writes FQNs when there is an assembly being referenced: https://github.com/dotnet/roslyn/blob/2f32bf87e211fe5319c94f442c4ad56254bc75e0/src/Compilers/Core/Portable/PEWriter/TypeNameSerializer.cs#L194

Cecil reading always uses module.TypeSystem.CoreLibrary when it cannot find a type definition (the current behavior of AsmResolver): https://github.com/jbevain/cecil/blob/3136847ea620fb9b4a3ff96bc4f573148e8bd2e4/Mono.Cecil/TypeParser.cs#L356

Cecil writing follows the ECMA section to the letter and only omits it when the assembly being referenced is exactly current module or mscorlib (this behavior is absolutely incorrect and almost certainly has real issues, I just cannot be bothered to synthesize examples of it, this fails when referencing mscorlib for any type that is not today in System.Private.CoreLib and then loading that attribute with CoreCLR): https://github.com/jbevain/cecil/blob/3136847ea620fb9b4a3ff96bc4f573148e8bd2e4/Mono.Cecil/TypeParser.cs#L521

dnLib reading does the same behavior as current AsmResolver and Cecil, attempting current module, then the referenced corlib: https://github.com/0xd4d/dnlib/blob/c78d296c522aae0520df2afd825d48266321cf36/src/DotNet/CustomAttributeReader.cs#L24

dnLib writing has an option flag for whether to enable the same optimization that AsmResolver currently employs: https://github.com/0xd4d/dnlib/blob/c78d296c522aae0520df2afd825d48266321cf36/src/DotNet/Writer/Metadata.cs#L182-L196

Even Cecil is technically wrong here, with respect to what CoreCLR does! The only actually correct thing to do is what Roslyn does, but that poses a problem when trying to load potentially poorly authored assemblies, because there's not a good answer for what to do.

Proposed solution(s)

1. Formally deprecate (e.g. in an ECMA augment) omitting the assembly for corelib types
2. Make CoreCLR (and Mono, if necessary) resolve such types through the mscorlib forwarder assembly (and maybe other forwarder assemblies depending on the source assembly's defined targetframework?)

• .NET Framework assemblies authored according to spec will load properly, though there is a risk that some incorrectly-authored .NET Standard or .NET Core assemblies will fail to resolve properly without checking the defined TargetFramework

Alternatively:

Augment ECMA to specify resolving-through System.Runtime instead of mscorlib, and adjust CoreCLR and Mono appropriately

• This sucks, because not specifying the assembly sucks in the first place.

A slightly more out-there idea is to rev the CA blob format and deprecate the string form entirely, replacing it with an encoded TypeDef/TypeRef/TypeSpec token and using all of the goodness of the .NET metadata format here, too.

[MichalStrehovsky]

Related: #24479, #19689.

Given the resolution of those, I think we'd want to formally deprecate omitting the assembly for corelib types in custom attribute blobs. It is true that compilers don't actually know what assembly a type could end up in, with the small exception of things like System.Object. The "core assembly" reference assembly provided at compile time will not match the real implementation assembly and it could be mscorlib.dll, netstandard.dll, or System.Runtime.dll, depending on how one compiles things. I don't think we'd want to probe them all. The other option would be to use mscorlib but that was rejected.

We keep track of our ECMA augments at https://github.com/dotnet/runtime/blob/c915ce98b200296f26e58c40e2d777d635a194c7/docs/design/specs/Ecma-335-Augments.md. Would you be willing to contribute?

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/area-system-reflection
See info in area-owners.md if you want to be subscribed.

[nike4613]

We keep track of our ECMA augments at https://github.com/dotnet/runtime/blob/c915ce98b200296f26e58c40e2d777d635a194c7/docs/design/specs/Ecma-335-Augments.md. Would you be willing to contribute?

I'd be happy to, whatever is decided.

In the discussion on the C# discord @GrabYourPitchforks suggested it might be reasonable to write an errata for. Is there a good place for that?

[tannergooding]

The augments doc is effectively that errata. It contains all the modifications, corrections, or additional annotations that should be taken with ECMA-335 to account for modern .NET.

There are likely a plethora of edge cases that aren't currently covered.

[tannergooding]

This is most notably a problem for System.Uri: it is in the reference corelib (System.Uri) on .NET Core and .NET Standard, but its implementation is in System.Private.Uri, not System.Private.CoreLib, so a CA blob that contains System.Uri will fail to resolve!

Notably System.Uri is originally documented as living in System.dll and not mscorlib.dll (as per ECMA TR-84), it being resolvable isn't guaranteed on .NET Framework or other runtimes either.

As discussed on Discord, what is actually guaranteed to live in the "system library" is much looser than what .NET Framework may have historically done for its own layering purposes and so this feature in general can be very non-deterministic across various implementations or even over time for versions of a single implementation.

I don't think we can ever remove the support, but I do think it would be beneficial to explicitly recommend against people using it and/or deprecating it due to the types of problems it can cause.

[jkotas]

The default fallback is frequently used for core intrinsic types like System.Int32 or System.String. I do not see a problem with that.

I agree that it is not a good idea to depend on the default fallback for arbitrary types when the type name is produced and resolved in two different type universes.

[reflectronic]

Out of curiosity: is there a reason the custom attribute blob uses serialized type names instead of metadata tokens?

[MichalStrehovsky]

Out of curiosity: is there a reason the custom attribute blob uses serialized type names instead of metadata tokens?

I don't think anyone remembers. Each custom attribute blob starts with a version number (that is always v1) so maybe not using tokens was a way to keep the format and contents of the custom attribute blob completely separate from rest of the file format. I can only guess. We haven't really needed this extensibility. The blob version number and textual type names are just a waste of space.

[KalleOlaviNiemitalo]

In dotnet/csharpstandard#1299 (comment), I suggested using a new blob version number to add support for array covariance in attribute arguments. I don't have high hopes of that getting implemented, though.