How to get solution path in .NET code analyzer

Question

How do you get access the file path to the project/solution being compiled inside a Roslyn code analyzer? I need to verify the code against some spec files stored relative to the code. Things that do NOT work:

SyntaxTreeAnalysisContext.Tree.FilePath
Assembly.GetExecutingAssembly().Location
AppDomain.CurrentDomain.BaseDirectory
Environment.CurrentDirectory
Path.GetFullPath(relativePath)

Answer 1

Analyzers exist below the Workspace level (they're run directly by the compiler), so the solution may not exist.

For complicated reasons, they aren't created by MEF, so there is no easy way to get to it even if it does exist.

From within VS, you can find the global service provider (eg, ServiceProvider.GlobalProvider ), then get SComponentModel (the root of VS's own MEF graph) and grab Roslyn's VisualStudioWorkspace from that. Beware that this is a somewhat brittle approach, and will not work at all outside VS.

Even within VS, this will break in strange ways for analyses in Preview panes, Miscellaneous Files, and other contexts that are not part of the global solution.

Answer 2

It's not possible to get solution from analyzer or fixer without reflection.

Use additional files to store settings.

In project:

<ItemGroup>
  <AdditionalFiles Include="MyConfig.config" />
</ItemGroup>

In analyzer:

private const string ConfigFileName = "MyConfig.config";

private static string LoadConfig(ImmutableArray<AdditionalText> additionalFiles, CancellationToken cancellationToken)
{
    var file = additionalFiles.SingleOrDefault(f => string.Compare(Path.GetFileName(f.Path), ConfigFileName, StringComparison.OrdinalIgnoreCase) == 0);
    if (file == null)
    {
        return null;
    }

    var fileText = file.GetText(cancellationToken);

    using (var stream = new MemoryStream())
    {
        using (StreamWriter writer = new StreamWriter(stream, Encoding.UTF8, 1024, true))
        {
            fileText.Write(writer, cancellationToken);
        }

        stream.Position = 0;

        using (var reader = new StreamReader(stream))
        {
            return reader.ReadToEnd();
        }
    }
}

private static void HandleCompilationStart(CompilationStartAnalysisContext context)
{
    var config = LoadConfig(context.Options.AdditionalFiles, context.CancellationToken);
}

Answer 3

I figured out a way to do this through reflection, I've only tested this in windows environment.

public static class RoslynExtensions
{
    public static Solution GetSolution(this SyntaxNodeAnalysisContext context)
    {
        var workspace = context.Options.GetPrivatePropertyValue<object>("Workspace");
        return workspace.GetPrivatePropertyValue<Solution>("CurrentSolution");
    }

    public static T GetPrivatePropertyValue<T>(this object obj, string propName)
    {
        if (obj == null)
        {
            throw new ArgumentNullException(nameof(obj));
        }

        var pi = obj.GetType().GetRuntimeProperty(propName);

        if (pi == null)
        {
            throw new ArgumentOutOfRangeException(nameof(propName), $"Property {propName} was not found in Type {obj.GetType().FullName}");
        }

        return (T)pi.GetValue(obj, null);
    }
}

Called from an analyzer like so:

public override void Initialize(AnalysisContext context)
{
    context.RegisterSyntaxNodeAction(AnalyzeConstDeclaration, SyntaxKind.FieldDeclaration);
}

public static void AnalyzeConstDeclaration(SyntaxNodeAnalysisContext context)
{
     var solution = context.GetSolution();
}

Answer 4

Here's another approach that works without VS; also brittle but for different reasons. :)

Find the csproj at file level by searching upwards the folder hierarchy starting with the path of the source file of the current syntax tree.

Of course it won't work under certain circumstances (if the source file is outside of the subtree of the csproj's folder, eg. linked files; or there are other stale csproj files lying around, etc.) The only safety net I could think of is checking whether the found csproj is really for the same assembly name that the current SemanticModel.Compilation.AssemblyName refers to so we don't end up with a csproj of some other random project.

Here's the code, see the method called FindProjectFile: https://nsdepcop.codeplex.com/SourceControl/changeset/view/75896#VS2015/source/NsDepCop.VisualStudioIntegration/ProjectAnalyzerRepository.cs