The existing API, Compilation.GetTypeByMetadataName, ceases to work in unpredictable situations where one of the compilation's references internally declares a type with the same name which is never visible to the compilation. This is a pitfall that hurts code generation. For example, if my code fix provider wants to pass ObsoleteAttribute to SyntaxGenerator, I might grab the symbol using GetTypeByMetadataName. This will mysteriously begin failing if a user begins targeting net5.0-windows where System.DirectoryServices gets automatically referenced, declaring its own internal ObsoleteAttribute. (Repro shown at #52037).
Roslyn itself is banning the use of Compilation.GetTypeByMetadataName in all its own analyzers: #43341
Additionally, please add an obsoletion warning or RSxxxx warning on uses of Compilation.GetTypeByMetadataName redirecting people to GetBestTypeByMetadataName. I can open a separate issue for this part if that is more helpful.
The existing API, Compilation.GetTypeByMetadataName, ceases to work in unpredictable situations where one of the compilation's references internally declares a type with the same name which is never visible to the compilation. This is a pitfall that hurts code generation. For example, if my code fix provider wants to pass ObsoleteAttribute to SyntaxGenerator, I might grab the symbol using GetTypeByMetadataName. This will mysteriously begin failing if a user begins targeting
net5.0-windowswhereSystem.DirectoryServicesgets automatically referenced, declaring its own internal ObsoleteAttribute. (Repro shown at #52037).Roslyn itself is banning the use of Compilation.GetTypeByMetadataName in all its own analyzers: #43341
Additionally, please add an obsoletion warning or RSxxxx warning on uses of Compilation.GetTypeByMetadataName redirecting people to GetBestTypeByMetadataName. I can open a separate issue for this part if that is more helpful.