Analyzer Post Analysis Summary

[Stekeblad]

When you write an analyzer you may find that you sometimes don't have enough information to decide if a diagnostic should be created or not. See for example the opening comments in #11750 and #25054 . In the code snippets in the referenced issues an action is registered (RegisterXxxAction) to collect information and a RegisterCompilationEndAction action is registered to process the result after the compilation finishes and report diagnostics where needed.

However, as mentioned in #11750, actions registered with RegisterCompilationEndAction does not get called with the default Visual Studio settings. The reason given is due to performance, but it does not mention what makes it slow. (Does the context offer access to some huge objects that are costly to create?)

Looking at the options offered by intellisense in my solution does not hint about there being any methods similar to RegisterCompilationEndAction in the aspect that it's called once after the analysis finished. If there is no method like that then I believe one would be useful. A method not intended for heavy processing or searching through the solution but for summarising findings recorded during analysis and reporting diagnostic based on that.

Another example is this class in one of my projects where RegisterCompilationEndAction only goes over a provided list, check a condition and if true reports some diagnostics. It does not need access to anything that seems heavy on performance.

Summary: I am looking for a method for registering actions in an analyzer that is executed once at the end of the analysis process, that is enabled by default and not being as bad on performance as RegisterCompilationEndAction.

[333fred]

The reason given is due to performance, but it does not mention what makes it slow.

In order to run a CompilationEnd action, the entire compilation must be analyzed, not just a small part. Other analysis options can be scoped appropriately, such the analyzer only needs to be rerun on a small section of code whenever it changes, not on the entire codebase.

In order to best suggest how to structure your analysis pass, we'd need to understand what you're actually trying to do with it. What is the analysis you're trying to write?

[Stekeblad]

I am scanning the code base for attributes of a specific type. Those attributes should have a GUID-parameter. The GUIDs and where they are found is recorded, after the analysis finishes I want to check if any GUID appeared more than once and create diagnostics for all attributes it appears in.

To get a complete list, of course the entire solution/project must be analysed. However, I believe it's worth reporting results from a partial analysis as well, if there are any. From what I can see that is not currently possible. Currently the analyzer can't even find attributes with reused GUIDs if they appear next to each other without a full analysis.

In order to run a CompilationEnd action, the entire compilation must be analyzed

What causes the entire compilation to be analyzed? Running the Clean Solution command, deleting the bin and obj folder followed by Rebuild Solution to force the entire solution to build appears to not also mean analyzing the entire compilation. Rebuild fails when installing analyzers as a nuget package but installing as an Visual Studio extension reports nothing in 17.11.0.

Because reusing GUIDs will cause the application to crash at startup I have set it's severity to error and if I can't trust CompilationEnd actions to be called I hope to find another way to register an action to summaries the results at the end of the current analysis, being it scoped to the current document, the entire solution or anywhere between.

[333fred]

but installing as an Visual Studio extension reports nothing in 17.11.0

We don't recommend this approach anymore. Use the nuget package.

What causes the entire compilation to be analyzed?

The fact that you asked for it. That's what CompilationEnd implies: at the end of compilation. There's no incrementality here, no way to just partially rerun. Custom state from the previous run can't be reused.

Currently the analyzer can't even find attributes with reused GUIDs if they appear next to each other without a full analysis.

You could do a SymbolEnd analysis, which could detect duplicates on the same type, but I'm really not certain that's worth it. You'll have to think about how to not report an error on that twice (once at symbol end, once at compilation end), and while it's probably doable, it just doesn't seem worth it. Ultimately, an analysis like this, while useful, can't be done efficiently, and is relegated to a full build. I agree it's not ideal, but I don't have any better solutions for you.

[Stekeblad]

but installing as an Visual Studio extension reports nothing in 17.11.0

We don't recommend this approach anymore. Use the nuget package.

That explains a few things!

I wrote most of my comments above based on observations from debugging the solution (solution is based on the Visual Studio template for analyzers, it installs the analyzers as an extension to a separate VS configuration). Nuget works better.

Thank you for all your answers!