API: Analyzer redirecting

Background and Motivation

As part of https://github.com/dotnet/sdk/issues/42087 (see also https://github.com/dotnet/sdk/pull/42437 for design doc), we want to introduce a VSIX deployed as part of the dotnet/sdk repo which would be able to control how analyzers are loaded in Roslyn. Specifically, it should be able to redirect analyzers that would normally load from SDK to analyzers that will be deployed as part of Visual Studio install. The intention is to avoid compiler version mismatch (the analyzers from SDK can reference an incompatible version of Roslyn whereas the VS-inserted analyzers will match the Roslyn coming in the same VS).

Proposed API

/// <summary>
/// Any MEF component implementing this interface will be used to redirect analyzer assemblies.
/// </summary>
[Experimental(...)]
public interface IAnalyzerAssemblyRedirector
{
    /// <summary>
    /// Consulted whenever an <see cref="AnalyzerFileReference"/> is created to determine its full path.
    /// </summary>
    /// <param name="fullPath">
    /// Original full path of the analyzer assembly.
    /// </param>
    /// <returns>
    /// The redirected full path of the analyzer assembly
    /// or <see langword="null"/> if this instance cannot redirect the given assembly.
    /// </returns>
    /// <remarks>
    /// If two redirects return different paths for the same assembly, no redirection will be performed.
    /// </remarks>
    string? RedirectPath(string fullPath);
}

Usage Examples

[Export(typeof(IAnalyzerAssemblyRedirector))]
public sealed class SdkAnalyzerAssemblyRedirector : IAnalyzerAssemblyRedirector
{
    public string? RedirectPath(string fullPath)
    {
        if (AnalyzerMap.TryGetValue(fullPath, out string redirectedFullPath))
        {
            return redirectedFullPath;
        }

        return null;
    }
}

Alternative Designs

Reuse the existing internal IAnalyzerAssemblyResolver API. It has method Assembly? ResolveAssembly(AssemblyName). That would be less efficient (OOP serialization would need to load the assembly). The resolver API has a slightly different purpose - it allows loading the assembly in a specific AssemblyLoadContext, for example. Both APIs should be usable together.

Risks

The API is marked Experimental, so we should be able to change/remove it at any point if we want.

API Review

What assembly should this go in?
- Workspaces may be nice?
- Does the IDE need to be able to know the real paths involved?
- Will VBCS compiler need to do the mapping as well?
  - We can't currently think of a reason
- Seems like using in the compiler layer outside of VS might break MSBuild incremental builds?
- If it goes in the workspaces layer, we can potentially make it internal, which seems like a nice benefit.
Should it be async?
Single, full paths aren't great.
- Should we try to design something for multiple?
- There is an implicit contract that everything in one folder needs to redirect to another folder.
- The assembly load would already work fine if they end up in different ALCs, because of backcompat requirements.

Conclusion: Investigate making the API internal in the workspaces layer.

dotnet / roslyn