Feature 'CodeLens references' is currently unavailable due to an internal error

[ldematte]

Version Used: VS 2019 16.9.2, 16.9.3 and also the latest 16.10 preview

Steps to Reproduce:

The error in subject appears using code generators.
Upon opening a file in a project that uses the generator the error appears, multiple (dozens) of times.
Stack trace:

StreamJsonRpc.RemoteInvocationException: Object reference not set to an instance of an object.
   at StreamJsonRpc.JsonRpc.<InvokeCoreAsync>d__139`1.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at System.Threading.Tasks.ValueTask`1.get_Result()
   at System.Runtime.CompilerServices.ConfiguredValueTaskAwaitable`1.ConfiguredValueTaskAwaiter.GetResult()
   at Microsoft.CodeAnalysis.Remote.BrokeredServiceConnection`1.<TryInvokeAsync>d__17`1.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at Microsoft.VisualStudio.Telemetry.WindowsErrorReporting.WatsonReport.GetClrWatsonExceptionInfo(Exception exceptionObject)
RPC server exception:
System.NullReferenceException: Object reference not set to an instance of an object.
      at Microsoft.CodeAnalysis.CodeLens.CodeLensReferencesService.<TryGetMethodDescriptorAsync>d__8.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.CodeLens.CodeLensReferencesService.<>c__DisplayClass9_0.<<FindReferenceMethodsAsync>b__0>d.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.CodeLens.CodeLensReferencesService.<FindAsync>d__1`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.RemoteCodeLensReferencesService.<>c__DisplayClass5_0.<<FindReferenceMethodsAsync>b__0>d.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 System.Threading.Tasks.ValueTask`1.get_Result()
      at Microsoft.CodeAnalysis.Remote.BrokeredServiceBase.<RunServiceImplAsync>d__12`1.MoveNext()
   --- End of stack trace from previous location where exception was thrown ---
      at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
      at Microsoft.VisualStudio.Telemetry.WindowsErrorReporting.WatsonReport.GetClrWatsonExceptionInfo(Exception exceptionObject)

The solution that triggers the error is available at https://github.com/ldematte/TheRing
Just compile, open Program.cs in TheRing.Example.Inproc, and scroll a bit inside the code.

Expected Behavior:
No exception

[vrenken]

We see the same issue as @ldematte in a similar Roslyn generator solution:
https://github.com/vrenken/EtAlii.Generators

Compile, and then opening Source\EtAlii.Generators.Stateless.Tests\StateMachines\SimpleStateMachine.cs triggers the same codelens error and above mentioned exception.

The issue shows up Visual Studio (16.9.3), but not in Rider (2021.1.1).

[bjornenalfa]

I get this issue whenever I view a file with properties/methods that are referenced by an automatically generated file. CodeLens works but the constant spam of error messages is annoying.

[koenbeuk]

Same issue here: https://github.com/koenbeuk/ScenarioTests

Each file that uses this generator (e.g. https://github.com/koenbeuk/ScenarioTests/blob/master/samples/BasicSample/ScenarioTest1.cs) raises this error when opening the file in VS 2019 (16.9.4) and VS 2019 preview. No further side effects have been noted

[CyrusNajmabadi]

@jasonmalinowski do yuo know what we woudl need to do to make CodeLens SG aware?

[jasonmalinowski]

Two answers:

We fixed #51686 in Preview 2, which I think will address the crash that @ldematte is reporting. If people are still seeing this in Preview 2 do speak up. This bug was filed prior to Preview 2 shipping so I'm guessing that was using preview 1.

Making code lens work when you open a generated file to view references to generated symbols is coming as a part of #52094 and an a non-open-source fix I have to make to the CodeLens tagger.

[koenbeuk]

@jasonmalinowski

This bug was filed prior to Preview 2 shipping so I'm guessing that was using preview 1.

This bug indeed seems to have been resolved in Preview 2!

so I'm guessing that was using preview 1

This bug is also present with the current stable release (16.9.4)

[jasonmalinowski]

Yeah, this will impact current stable; I don't know if we'd do a backport of the fix at this time, but we'll keep that in mind.

[ldematte]

We fixed #51686 in Preview 2, which I think will address the crash that @ldematte is reporting. If people are still seeing this in Preview 2 do speak up. This bug was filed prior to Preview 2 shipping so I'm guessing that was using preview 1.

Yes, I can confirm I was using Preview 1 at the time of reporting; I have updated to Preview 2 and the issue is fixed on my solution, no more spurious messages. Thanks!

[ldematte]

Since making code lens work when you open a generated file is already tracked by the linked issue, and the bug in the subject is indeed fixed, I suppose this could be closed?

[jasonmalinowski]

Yep, closing, and due to the extra votes starting a conversation about a backport.

[jasonmalinowski]

And to follow up since a few other folks have ran into this: this will be fixed with 16.10. Based on internal schedules if we got a patch out for 16.9 it wouldn't get in your hands that much faster than just waiting for 16.10, so just best to sit tight and wait for a bit longer.