`UnusedOpensAnalyzer` is constantly executed even then disabled causing VS unresponsiveness

[xperiandri]

https://developercommunity.visualstudio.com/t/F-UnusedOpensAnalyzer-is-constantly-e/10939016

Looks like UnusedOpensAnalyzer constantly crashes and tries to execute again. Which causes Visual Studio to hang up to 30 seconds. Makes Visual Studio completely unusable!
Even when UnusedOpensAnalyzer is disabled in settings, it is still executed!

Repro steps

1. Clone https://github.com/Ecierge/Elmish.Uno/tree/Ecierge
2. Check out Ecierge branch
3. Open Elmish.Uno.sln
4. Expand Elmish.Uno project
5. Open Binding.fs or BindingT.fs
6. See how UnusedOpensAnalyzer constantly appears in logs

Expected behavior

1. All code fixes can be disabled if unchecked in VS settings
2. Code fixes do not go into the crash loop

Actual behavior

UnusedOpensAnalyzer and one more code fix cannot be disabled.
UnusedOpensAnalyzer code fix goes into crash loop

Known workarounds

Unfortunately, no, and it drastically affects the development productivity

Related information

Provide any related information (optional):

• Operating system 10.0.26100.4351
• .NET Core 9.0.302
• FSharp.Core 9.0.202
• Visual Studio Version 17.14.9 Preview 1.0

[majocha]

Yes, UnusedOpensAnalyzer will still get called by Visual Studio even when disabled in options. The way it is currently handled is that it checks the option and just returns empty value if disabled.

Are you getting the error bar on top when it crashes? Sometimes a stack trace is available.

I tried to repro the steps, but it seems to work ok for me. For example it takes a fraction of second to correctly point out System.Collections.Generic as unused in BindingT.fs when I enable it and the performance is generally fine in the repo.

[majocha]

Although it seems the performance is not great with Transparent Compiler disabled.

[xperiandri]

Both compilers performance is terrible for me. VS constantly hangs

[majocha]

I suspect it may be something else not the analyzer.
I'm trying to do some edits in the repo, some code searches, run tests, but it behaves ok:

What I have enabled is:

and and

For reference on my machine it builds in 9 sec, all tests run in 3 sec.

[xperiandri]

If I enable these, Visual Studio is dying

This is the smallest repo I have visible effects (if you have access to the screen recording, you can see even the cursor moving hangs). But in my production 42 project solutions (filtered total of 108), usability is absolutely terrible (at least compared to C#).

There is definitely some work that constantly happens on the UI thread...

[xperiandri]

Are you getting the error bar on top when it crashes? Sometimes a stack trace is available.

Yes, I do. This and the other with Roslyn analyzers running some F# analysis

StreamJsonRpc.RemoteInvocationException: Project of ID (ProjectId, #f092601a-f426-4742-9d08-7464e6e01adf - C:\Users\Andrii\Dev\PropertyManagement\Infrastructure\FSharp\FSharp.fsproj ({113D8DE8-FFC8-EBAF-BB27-01302469159C})) is required to accomplish the task but is not available from the solution
   at StreamJsonRpc.JsonRpc.<InvokeCoreAsync>d__156`1.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at Microsoft.CodeAnalysis.Remote.BrokeredServiceConnection`1.<TryInvokeAsync>d__17.MoveNext()
RPC server exception:
System.InvalidOperationException: Project of ID (ProjectId, #f092601a-f426-4742-9d08-7464e6e01adf - C:\Users\Andrii\Dev\PropertyManagement\Infrastructure\FSharp\FSharp.fsproj ({113D8DE8-FFC8-EBAF-BB27-01302469159C})) is required to accomplish the task but is not available from the solution
      at Microsoft.CodeAnalysis.Shared.Extensions.ISolutionExtensions.GetRequiredProject(Solution solution, ProjectId projectId)
      at Microsoft.CodeAnalysis.EditAndContinue.DebuggingSession.UpdateBaselines(Solution solution, ImmutableArray`1 rebuiltProjects)
      at Microsoft.CodeAnalysis.EditAndContinue.RemoteEditAndContinueService.<>c__DisplayClass15_0.<UpdateBaselinesAsync>b__0(Solution solution)
      at Microsoft.CodeAnalysis.Remote.BrokeredServiceBase.<>c__DisplayClass16_0.<<RunServiceAsync>b__1>d.MoveNext()
   --- End of stack trace from previous location ---
      at Microsoft.CodeAnalysis.Remote.RemoteWorkspace.<>c__DisplayClass7_0`1.<<RunWithSolutionAsync>g__ProcessSolutionAsync|1>d.MoveNext()
   --- End of stack trace from previous location ---
      at Microsoft.CodeAnalysis.Remote.RemoteWorkspace.RunWithSolutionAsync[T](AssetProvider assetProvider, Checksum solutionChecksum, Boolean updatePrimaryBranch, Func`2 implementation, CancellationToken cancellationToken)
      at Microsoft.CodeAnalysis.Remote.RemoteWorkspace.RunWithSolutionAsync[T](AssetProvider assetProvider, Checksum solutionChecksum, Boolean updatePrimaryBranch, Func`2 implementation, CancellationToken cancellationToken)
      at Microsoft.CodeAnalysis.Remote.BrokeredServiceBase.RunWithSolutionAsync[T](Checksum solutionChecksum, Func`2 implementation, CancellationToken cancellationToken)
      at Microsoft.CodeAnalysis.Remote.BrokeredServiceBase.<>c__DisplayClass16_0.<<RunServiceAsync>b__0>d.MoveNext()
   --- End of stack trace from previous location ---
      at Microsoft.CodeAnalysis.Remote.BrokeredServiceBase.RunServiceImplAsync(Func`2 implementation, CancellationToken cancellationToken)

[majocha]

Yes, I'm seeing sometimes some analyzers crashing, but it's transient and usually connected with things like changing branches, adding files to the project, moving files around.
I'm trying to trigger something like this in the Elmish.Uno.sln, for example by moving BindingT.fs up and out of order in the file list, but it is still behaving well. Errors show up fast and go away fast.

I suppose you tried the usual things like deleting .vs folder?

[xperiandri]

In rare cases, I delete .vs folder.
Maybe I can give you access to the big project that is affected?
Or can you guide me on how to reproduce that on my side?

[majocha]

Let's see first what the MS team says, if this is something triggered between Roslyn, VS platform and F# extension I may not have the knowledge and skills to do anything.

One thing that may be stupid but I'd try it:
open your solution in the VS experimental instance with the latest and greatest version F# extension.You will need to add the "Visual Studio extension developement" workload in VS installer app. Then the steps are:

1. checkout main from this repo, dotnet/fsharp

Build.cmd -c Release

3. From "Developer Command Prompt for VS 2022 Preview":

devenv.exe /rootsuffix RoslynDev

This will give you kind of clean slate, and at least we'll know if it still repros with the latest F# extension.