Keeping Analyzer state between projects of the same solution

[steffenloesch]

It seems like solution-wide analysis (like finding symbols) is not supported with the current version of Analyzers: http://stackoverflow.com/questions/23203206/roslyn-current-workspace-in-diagnostic-with-code-fix-project.

In order to have some sort of solution-wide warning, is there a way to keep Analyzer state between compilations of the same solution?

My use-case is that I want to analyze type-creation, in order to get a set of 'bad types'. At a later stage, I want to warn of usages of those 'bad types', even if that usage is in a different project of the same solution.

[steffenloesch]

Is there any update on this? I understand that there are good reasons for restricting Analyzers to the current compilation, but it also severely restricts Analyzers in my view. If your codebase is spread over several projects in the same solution, then pretty simple scenarios (like the one is described above) are very hard/impossible to implement with Analyzers.

Another scenario that currently does not seem to be supported is a 'go to definition/implementation' across projects. It would be great if there were some APIs for that.

The solution described here #6324 might mitigate some of that, but it's also not a great solution for the scenario I described. Some more directed questions:

• Are there any guarantees for instance or static variables of Analyzers across compilations?
• Are there plans for having Analyzers that support workspaces/solutions?

[jmarolf]

is there a way to keep Analyzer state between compilations of the same solution?

Symbols are never guaranteed to be the same across compilations. You cannot cache a symbol from one compilation and compare it against one from a different compilation. The behavior is undefined.

Are there any guarantees for instance or static variables of Analyzers across compilations?

Analyzers are loaded and initialized once in Visual Studio, and then passed the information they requested as it occurs across compilations. On the commandline the compiler loads, initializes, and passes information from a single compilation. Analyzers are expected to be functionally pure and free-threaded. State aggregation is expected to happen through Start/End registration, but this state is only kept for the compilations lifetime.

Are there plans for having Analyzers that support workspaces/solutions?

A lot of the advantages of Analyzers is that they are a first class citizen of the compiler that work everywhere the compiler works (ci servers, dev boxes, etc). Analyzing solutions is outside the realm of the compiler. We would ideally need something new to do handle passing workspace info to analyzers,and likely a new API to properly express this. All of this to say, we've talked about it and feel it something that we should do, but it not going to happen tomorrow. Unfortunately I can't really say when it will happen.

If you could list some scenarios that would take advantage of this, it would help us understand some inputs into the design. In your bad types example, could you explain why you need solution level analysis to accomplish this? Do you not know the names of the types ahead of time? Most of the time it should be possible to check if a type is present in a given compilation by looking up its name and then doing analysis on that type.

Finally

Another scenario that currently does not seem to be supported is a 'go to definition/implementation' across projects

Could you file a separate bug around this scenario? We should already have the needed API's to do this, its just a matter of making them public.

[steffenloesch]

Thanks for the very informative answer, @jmarolf !

Symbols are never guaranteed to be the same across compilations. You cannot cache a symbol from one compilation and compare it against one from a different compilation. The behavior is undefined.

I don't necessarily need to cache the symbol, a fully qualified type name would be enough in my case, and I could recreate the symbol from that for the compilation in question.

All of this to say, we've talked about it and feel it something that we should do, but it not going to happen tomorrow. Unfortunately I can't really say when it will happen.

That's great to hear. I personally think that this is a very very desirable feature.

In your bad types example, could you explain why you need solution level analysis to accomplish this? Do you not know the names of the types ahead of time?

I need to analyze the code of the type in question, to see if it is a bad type. I could do that once and then hard-code it in my Analyzer. However, I'm working with a changing codebase, so the list of bad types might be changing frequently, and I'd like my analyzer to support that without manual intervention (reanalyzing all types, updating the code of my Analyzer). One solution might be to have a pre-compile step that writes the list of bad types to a file, and have my Analyzer read it when it's run, but it would be nice if that could be done in the Analyzer directly.

Could you file a separate bug around this scenario? We should already have the needed API's to do this, its just a matter of making them public.

I just did that: #8144

[srivatsn]

I don't necessarily need to cache the symbol, a fully qualified type name would be enough in my case, and I could recreate the symbol from that for the compilation in question.

#6324 is tracking a proposal for an API that would let you share state like this.

#3797 is tracking the work to expose an API that would let an extension do some analysis at the workspace layer (and hence have access to Document\Project\Solution) level. Those analyzers would only run in VS and not at the commandline since the compiler doesn't know anything beyond a project.