Load analyzer satellite assemblies

[tmeschter]

Analyzers support localized strings for titles, messages, descriptions,
etc. through the LocalizableString types. The localized strings will
generally end up in a set of "satellite" assemblies ending in
.resources.dll, one per culture. For example, if your analyzer is in an
assembly "MyAnalyzer" and you provided localized strings for French
(e.g., the fr-FR culture) then the build will typically produce
bin\Debug\MyAnalyzer.dll and bin\Debug\fr-FR\MyAnalyzer.resources.dll.

However, we currently have no way to find these satellite assemblies
when the CLR asks for them via the AppDomain.AssemblyResolve event, so
we never actually output localized strings from analyzers. The fix is to
simply look for the assemblies in culture-specific directories next to
the analyzer.

[tmeschter]

@srivatsn @shyamnamboodiripad @mavasani @heejaechang @jmarolf @JohnHamby Could you take a look, please?

[jmarolf]

Tests?

[tmeschter]

Oh, all right. This turns out to be very difficult to do in a unit test, unfortunately. There probably isn't a good way to do it without refactoring the API and separating the assembly loader from the AnalyzerFileReference. I'll have to think about that some more.

[mavasani]

Should we overwrite the directory path only if this directory actually exists: Path.Combine(directoryPath, requestedAssemblyIdentity.CultureName); ? This we way we can fallback to the loadedAssembly directory if no such sub-folder exists.

[mavasani]

Additionally, is it also worth looking for sub-folder with name: "CultureInfo.GetCultureInfo(requestedAssemblyIdentity.CultureName)?.LCID"?

[tmeschter]

But why would we fall back?

[srivatsn]

On the LCID thing - will the CLR assembly resolution for normal contexts pick up a Japanese resource if it was in the 1041 directory for example? If so, yes we should look for the LCID directory - otherwise I don't think there'll be a scenario where the user will expect it.

[tmeschter]

No, it will not automatically look in a 1041 directory. The probing logic is described here:
https://msdn.microsoft.com/en-us/library/15hyw9x3(v=vs.100).aspx

[mavasani]

👍

[tmeschter]

For the sake of good design and testability, we need to separate the concept of an AnalyzerFileReference from the mechanism we use to load assemblies. I'll update AnalyzerFileReference to take an instance of a new interface, IAssemblyLoader, instead of the current Func<string, Assembly>.

The InMemoryAssemblyLoader will become one implementation of IAssemblyLoader and we'll have another for loading VSIX-based analyzers.

[tmeschter]

After several attempts, I've decided there's no good way to really separate AnalyzerFileReference from the InMemoryAssemblyLoader. I've instead extracted out the code for generating a potential assembly path from an AssemblyIdentity and added unit tests just for that.

[tmeschter]

@jmarolf I've added tests.

[jmarolf]

@tmeschter thanks! 👍