Version Used:
VS2019 16.4.0 Preview 6
I have a huge number of red squiggles that will not clear despite no build errors. The project builds and runs fine.
As the solution contains IP I cannot publicly host it, but I would be willing to share it on a one on one if someone is directly looking at it and can guarantee the solution will be deleted afterwards. I can also do a screenshare or collaborate on gitter.
Expected Behavior:
When there are no build errors, the error log also shows no build errors, and there are no red squiggles show.
Actual Behavior:
Thousands of red squiggles, edit and continue does not work (due to the errors). Actual output log shows 0 errors and solution builds correctly.
More information. For background read this post (it has MS only video and attachments). The 10 second intellisense completion issue is now fixed by @CyrusNajmabadi waiting to be merged however the error list remains.
https://developercommunity.visualstudio.com/content/problem/817870/intellisense-lag-and-huge-number-of-false-red-squi.html
@rolandh Thanks for the report!
@mavasani I think you've interacted a bit with Roland on developercommunity. I've been conversing with him on Gitter and he indicates that he has a project where this issue repros 100% of the time simply by opening the project and doing nothing else.
Would it be possible for you to reach out to him on Gitter (he's got the same alias there) to see about getting his project so you can just try this out internally? I imagine since the repro is so simple it might allow you to determine the cause almost immediately. He also has the design-time-build logs, but would prefer to share with you directly.
Note: Roland is on Australian time, so it may take a little back-and-forth to get in touch with each other.
Thanks!
Yes, just back from the thanksgiving break. Last week I did look at his design time build logs and they did not have any indication on why the undefined type errors are being reported - likely some issue with skeleton assemblies, but would need to debug it. @rolandh I will contact you on gitter to get access to your solution. Thanks!
That's great @mavasani . Thanks so much!
I was able to track down the root cause for this issue, and also provided a workaround to @rolandh offline.
Tagging @jasonmalinowski, who is expert on VS project system layer on our team, and @tmat who has been investigating how to properly report VS-specific diagnostics in Roslyn. Let me expand on the findings:
P1 has a ProjectReference to project P2 and project P2 has a metadata Reference to P2.dll. Latter gets converted to a project reference via our metadata to project reference conversion logic.InvalidOperationException in CheckNotContainsTransitiveReference over here when attempting to add project and metadata references.P1.P2.dll is unnecessary.InvalidOperationException does not translate to any diagnostic in the error list, so user is given no information about what went wrong under the covers and how to resolve their issue. Ideally, the circular reference, or in fact any such project system anomalies for which we throw exceptions in the Workspace layer, should be translated to diagnostics in error list by VS layer, so it helps the user towards fixing their project/solution. @jasonmalinowski do we have any issue tracking such work? I can file one otherwise.Also tagging @sharwell who initially looked at @rolandh's VS feedback issue.
I agree that invalid inputs from project system should be reported as diagnostics and not crash/throw.
https://github.com/dotnet/roslyn/issues/39904 tracks the cyclic reference issue.
Thank you for digging through this and finding the root cause. Any ideas how the cyclic reference could get added if the UI normally blocks you from doing such things?
I am suspecting it got added with a manual edit or some merge across branches.
It appears some tooling did something funny. Going back through our git commits it appears that not only was a circular reference added but the reference was added 6x in a row to the csproj file. This is not something a human would do and I can't see how a git merge would do it either.
It is possible it was resharper or the intellisense bulb that did it. I tried to make a repro solution and get this to occur but I have failed to achieve this so far. I tried with resharper on off and neither resharper or intellisense suggested to add a circular reference.
Anyway this is really a different issue (eg how the circular reference got added in the first place) so it is getting a bit off topic. If I can repro it I will start a new issue.
Thanks everyone for helping out on this. Hopefully we can resolve the IDE dying if a circular reference occurs, or at least have some kind of build warning/message saying that a circular reference has been added. Solving the root cause of how it got there in the first place would be great a well, but that may not be possible for me to repro, also if it turns out it was resharper its not really your problem anyway.
Duplicate of #39904
Most helpful comment
I was able to track down the root cause for this issue, and also provided a workaround to @rolandh offline.
Tagging @jasonmalinowski, who is expert on VS project system layer on our team, and @tmat who has been investigating how to properly report VS-specific diagnostics in Roslyn. Let me expand on the findings:
P1has aProjectReferenceto projectP2and projectP2has a metadataReferencetoP2.dll. Latter gets converted to a project reference via our metadata to project reference conversion logic.InvalidOperationExceptioninCheckNotContainsTransitiveReferenceover here when attempting to add project and metadata references.P1.P2.dllis unnecessary.InvalidOperationExceptiondoes not translate to any diagnostic in the error list, so user is given no information about what went wrong under the covers and how to resolve their issue. Ideally, the circular reference, or in fact any such project system anomalies for which we throw exceptions in the Workspace layer, should be translated to diagnostics in error list by VS layer, so it helps the user towards fixing their project/solution. @jasonmalinowski do we have any issue tracking such work? I can file one otherwise.