[This issue clones #52118 but without asking for two things in one]
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
Best is short, but Accessible or Visible might be more self-explanatory. You're getting the single type that is accessible anywhere within the compilation, if there is exactly one.
[This issue clones #52118 but without asking for two things in one]
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
Bestis short, butAccessibleorVisiblemight be more self-explanatory. You're getting the single type that is accessible anywhere within the compilation, if there is exactly one.