DotNet SDK 2.1.300 no longer loads satellite assemblies for StyleCop.Analyzers

[vweijsters]

A localization issue was reported for StyleCop.Analyzers when using SDK 2.1.300 (see DotNetAnalyzers/StyleCopAnalyzers#2715).
I've done builds with diagnostic logging for 2.1.201 and 2.1.300 and I've compared the output.
The logging for 2.1.201 shows that satellite assemblies for StyleCop.Analyzers are detected and used. The satellite assemblies are absent from the log file for 2.1.300.

TestDotNet.zip contains the test project used and the diagnostic log files when building with 2.1.201 and 2.1.300.

[livarcocc]

@dsplaisted @nguerrera can one of you take a look when you have a chance?

[nguerrera]

Hmm, I did change things to stop passing every analyzer satellite as an analyzer to the compiler. This appeared to be a bug with over-aggressive pattern matching for analyzer assemblies in assets file.

My expectation was that like any other assembly, analyzers would find their satellites by convention next to them in culture-specific sub-folders. Therefore, there would be no need to pass them to the compiler.

I suspect the issue is that on CoreCLR, the compiler has the same problem that MSBuild once had: dotnet/msbuild#2203. I further suspect that the over-aggressive pattern matching was masking that by forcing the compiler to pre-load all analyzer satellites. If I'm right, I doubt it was deliberately designed to work that way as it would be bad for performance to require satellites for unused cultures to be loaded.

(Aside: we shouldn't even have any pattern matching of our own to identify analyzer assemblies, but NuGet still hasn't been updated to identify them for us as they do for compilation and runtime assets: NuGet/Home#6279)

cc @agocke @jaredpar

[nguerrera]

This issue was moved to dotnet/roslyn#29014