Project-system: Analyzer dependencies showing as unresolved full paths

[drewnoakes]

Steps to reproduce:

1. Create a new .NET Core Console App
2. Add a package reference to xunit.analyzers
3. Build the solution
4. Close the solution
5. Re-open the solution
6. Expand the project's dependencies node
7. Notice there is no Analyzers node
8. Modify whitespace in the project file and save it (triggering a design-time build)
9. Notice an Analyzers node appears with unresolved child, which is a full path rather than the analyzer's name
   
10. Close and reopen the solution and the analyzers appear correctly
11. Modify the project file again (stays resolved)
12. Close and re-open the solution (stays resolved)
13. Build from VS then close/re-open solution and notice Analyzers node is missing again

Open questions:

• Why is the Analyzers node not initially present? This seems to happen if the build before opening the solution happened within VS.
• Why are analyzers appearing as paths and in unresolved state?

[drewnoakes]

As part of fixing this, add coverage of analyzers to the integration tests.

[drewnoakes]

Some notes to capture findings of investigations.

• It doesn't appear to vary based on SDK version
• It does reproduce in 16.2.3
• It does NOT reproduce in 15.9.15
• It seems related to a restored cache of DTB data

(EDIT removed incorrect git bisect log as I'd misidentified the good commit)

[DamianEdwards]

FYI still repros in 16.3.1 when working with ASP.NET Core projects:

[drewnoakes]

This is potentially caused by metadata filtering in the DTB cache for task items. From the (internal) ProjectServices repo:

MSBuild throws exceptions when we access path related properties on non-path items.
We try to prevent running into such frequent exceptions by detecting some common invalid path patterns.

This filtering applies when writing the cache, which fits with the above repro steps. My current hunch is that data needed by the Analyzers node is being filtered out by the cache, but this needs further investigation.

[drewnoakes]

Paths are shown for unresolved analyzer references:

https://github.com/dotnet/roslyn/blob/ef4e36fd040f77ba5103434101138598f4c6233f/src/VisualStudio/Core/SolutionExplorerShim/AnalyzerItem/AnalyzerItem.cs#L83-L93

EDIT: This is a red herring. Roslyn creates the full _Analyzers_ node for legacy projects, but for this project system it only populates diagnostic items. We have similar logic however:

https://github.com/dotnet/project-system/blob/9147bf8b3980cc4612b72faacc0337b4de600534/src/Microsoft.VisualStudio.ProjectSystem.Managed/Tree/Dependencies/Models/AnalyzerDependencyModel.cs#L49-L51

[drewnoakes]

This can be reproduced more easily by:

1. New ASP.NET Core Web Application (empty)
2. Close solution
3. Reopen solution

Deleting the .dtbcache file in the .vs folder between steps 2 and 3 fixes the problem, so the DTB caching in ProjectServices is looking like the culprit here.

---

EDIT The above worked for me five times in a row, but no longer does. It doesn't seem that deterministic. Running VS in the debugger makes it fail more often. Right now I'm Ctrl+F5'ing and can't repro it at all.

[DamianEdwards]

@drewnoakes really appreciate the persistence on this 👍

[ttaylor29]

@drewnoakes post helped me out! Thank you!

[drewnoakes]

Getting closer. This appears to be a race condition. If the VS instance is 'warm' (has previously had a solution open) then the problem triggers. The presence of the DTB cache factors in to the sequence of events, as it's much faster to read the cache than do a DTB. It also explains why using the debugger hasn't been helpful, as that changes timing too. I'm going to add some tracing to dig deeper.

[drewnoakes]

This has been fixed and will be released in 16.5.

[AssafAuo]

could be but 16.5 is not out yet

[keserwan]

This has been fixed and will be released in 16.5.

I just updated Visual studio to 16.4.4 and the issue was resolved.
The reference is fixed and no more yellow triangle.
Thanks.

[drewnoakes]

@keserwan glad it's working for you, but the fix is not present in that build. It will be in 16.5, and most likely in a preview.

[arphox]

I fixed this error by deleting the solution's .vs folder along with all bin and obj folders in all subprojects. All of these of course while VS was not running.

[oboro-san]

@arphox Thanks alot. Your suggestion worked for me

[davkean]

That will work until the next reload of the solution, the fix is in 16.5.