Type.FullName contains Type.AssemblyQualifiedName for generic arguments

[mdzieg]

Description

For a type, FullName returns FQAN for generic type arguments. It is inconsistent with what FullName returns for non-generic types.

Reproduction Steps

using System;
					
public class Program
{
	public static void Main()
	{
		Console.WriteLine(typeof(int).FullName);
		Console.WriteLine(typeof(int?).FullName);
	}
}

Expected behavior

System.Int32
System.Nullable`1[[System.Int32]]

Actual behavior

System.Int32
System.Nullable`1[[System.Int32, System.Private.CoreLib, Version=8.0.0.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e]]

Regression?

No response

Known Workarounds

This method returns the full type name with the assembly name.

	public static string GetStringRepresentation(this Type type)
	{
		if (type.IsGenericType)
		{
			var genericTypeDef = type.GetGenericTypeDefinition();
			var args = type.GetGenericArguments();

			var simplifiedArgs = string.Join(", ", args.Select(arg => $"[{arg.GetStringRepresentation()}]"));

			return $"{genericTypeDef.FullName}[{simplifiedArgs}], {type.Assembly.GetName().Name}";
		}

		return $"{type.FullName}, {type.Assembly.GetName().Name}";
	}

The following code:

		Console.WriteLine(typeof(int).GetStringRepresentation());
		Console.WriteLine(typeof(int?).GetStringRepresentation());

Results in:

System.Int32, System.Private.CoreLib
System.Nullable`1[[System.Int32, System.Private.CoreLib]], System.Private.CoreLib

Configuration

No response

Other information

Ideally there could be a property that returns FQAN, but without version and token. So this information could be serialized and used during deserialization even when the version of the assembly changes.

[dotnet-policy-service]

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

[jkotas]

The constituents of the generic instantiation can come from different modules. For example, consider Dictionary<HttpClient, XmlDocument>) that references 3 different assemblies. It is why Type.FullName works the way it works - Type.FullName can be roundtripped with Assembly.GetType API.

If you would like to invent custom serialization schemes for type names, it is best to implement them yourself. I do not expect there would be interest in adding custom serialization schemes for type names in the core libraries since direct serialization of type names is generally frowned upon.

[mdzieg]

The constituents of the generic instantiation can come from different modules. For example, consider Dictionary<HttpClient, XmlDocument>) that references 3 different assemblies. It is why Type.FullName works the way it works - Type.FullName can be roundtripped with Assembly.GetType API.

If you would like to invent custom serialization schemes for type names, it is best to implement them yourself. I do not expect there would be interest in adding custom serialization schemes for type names in the core libraries since direct serialization of type names is generally frowned upon.

I got your point. This is why in my logic I add AssemblyName after comma, not only FullName of the type. But I skip version, culture, and token.

To support such cases I would expect that framework falls back to:

System.Nullable`1[[System.Int32, System.Private.CoreLib]]

Instead of:

System.Nullable`1[[System.Int32, System.Private.CoreLib, Version=10.0.0.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e]]

That looks like mixed FullName with AssemblyQualifiedName. If version and token are necessary, AssemblyQualifiedName can be used.

[jkotas]

Changing the behavior of Type.FullName API like this would be a breaking change that's hard to justify.

[mdzieg]

Unfortunately, it is a breaking change. It may get introduced with the next major release and listed as a breaking change. There could be a feature flag. There could be a new property, for example, SimpleName. Or if others do not see value in this - ignored.

I hope I am not the only one surprised by this behavior.

[MichalPetryka]

Isn't typeof(int?).ToString() doing what you want? That gives System.Nullable`1[System.Int32].

So this information could be serialized and used during deserialization even when the version of the assembly changes.

You should never deserialize arbitrary types based on name, that's a surefire way of introducing CVEs into your code and the reason why BinaryFormatter was removed.

[mdzieg]

Isn't typeof(int?).ToString() doing what you want? That gives System.Nullable`1[System.Int32].

Thanks, somehow I missed this. I may switch to using this approach rather than implementing custom logic, as I probably will not need an assembly name.

You should never deserialize arbitrary types based on name, that's a surefire way of introducing CVEs into your code and the reason why BinaryFormatter was removed.

Thank you for pointing this out. Indeed it is a security vulnerability, but in my case it is justified, and I do not have another option (concrete type has to be serialized and deserialized from under property of type object).

Going back to the main topic, I still feel it is a bit inconsistent. FullName should not use FQAN for generics. But is it enough to justify changes?

[doesicool]

Going back to the main topic, I still feel it is a bit inconsistent. FullName should not use FQAN for generics. But is it enough to justify changes?

I also strongly agree with you that this behaviour is completely inconsistent and unexpected! I always wondered why it is implemented like that.

Isn't typeof(int?).ToString() doing what you want? That gives System.Nullable`1[System.Int32].

I would expect that Type.FullName (for generic types) return exatctly that what Type.ToString() is returning currently.

PS. @mdzieg consider renaming the title to "Type.FullName contains Type.AssemblyQualifiedName for generic arguments" for clarity and to make it easier to find.