dotnet / roslyn

The Roslyn .NET compiler provides C# and Visual Basic languages with rich code analysis APIs.
https://docs.microsoft.com/dotnet/csharp/roslyn-sdk/
MIT License
19.07k stars 4.04k forks source link

Completion offered for WinForms type that is not actually available #60583

Open AArnott opened 2 years ago

AArnott commented 2 years ago

Version Used: Dev 17.2 Preview 3 (32330.571.main)

Steps to Reproduce:

  1. Create a WPF app (.NET 6)
  2. Open the MainWindow.xaml.cs file. In the constructor, add a new line and type MainMenu.
  3. Press Ctrl+.

Expected Behavior:

Nothing offered.

Actual Behavior:

Completion for a Windows Forms type is offered: image

But this type does not exist in .NET 6. It last existed in .NET Core 3.0. See https://github.com/terrajobst/apisof.net/issues/15 for a discussion about this type's history. Upon selecting this completion, nothing happens. At least, not for several seconds. Eventually I get a "A task was canceled." dialog and a "Windows Forms" output window pane appears with this content (after having tried to activate the offered completion twice:

[06:18:37.6706695] Cannot update selection in server process as Session is not connected.

                   For information on how to troubleshoot the designer refer to the guide at https://aka.ms/winforms/designer/troubleshooting.
[06:20:31.6217596] [WinFormsApp1]: Timed out while connecting to named pipe: DesignToolsServer.5d8b3c95-714f-4c62-91df-b0ad36c1f4dc

                   For information on how to troubleshoot the designer refer to the guide at https://aka.ms/winforms/designer/troubleshooting.
[06:20:31.6577714] Microsoft.DotNet.DesignTools.Client.ServerException: Timed out while connecting to named pipe.
                      at Microsoft.DotNet.DesignTools.Client.Host.ServerProcess.<ConnectToStreamAsync>d__35.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.DotNet.DesignTools.Client.Host.ServerProcess.<LaunchAsync>d__28.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.DotNet.DesignTools.Client.Host.ServerHostFactory.<CreateHostAsync>d__7.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.DotNet.DesignTools.Client.DesignToolsClientLoader.<CreateClientAsync>d__28.MoveNext()

                   For information on how to troubleshoot the designer refer to the guide at https://aka.ms/winforms/designer/troubleshooting.
[06:20:31.6597708] System.Threading.Tasks.TaskCanceledException: A task was canceled.
                      at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
                      at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
                      at Microsoft.VisualStudio.WinForms.ProjectWatchers.ProjectWatcherService.ProjectWatcher.<IsLoaderDisposedAsync>d__56.MoveNext()
                   --- End of stack trace from previous location where exception was thrown ---
                      at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
                      at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
                      at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
                      at Microsoft.VisualStudio.WinForms.ProjectWatchers.ProjectWatcherService.ProjectWatcher.<>c__DisplayClass54_1.<<RestartServerProcessAndReloadDesignerIfRequired>g__RecreateDesignerSessionAndReloadDesignerAsync|1>d.MoveNext()
                   --- End of stack trace from previous location where exception was thrown ---
                      at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
                      at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
                      at Microsoft.VisualStudio.WinForms.ProjectWatchers.ProjectWatcherService.ProjectWatcher.<>c__DisplayClass54_0.<<RestartServerProcessAndReloadDesignerIfRequired>b__0>d.MoveNext()

                   For information on how to troubleshoot the designer refer to the guide at https://aka.ms/winforms/designer/troubleshooting.
sharwell commented 2 years ago

@genlu Would this situation be triggered by this option? image

CyrusNajmabadi commented 2 years ago

These crashes seem to be in: Microsoft.VisualStudio.WinForms.ProjectWatchers

@DustinCampbell do you know who might be able to help out here?

DustinCampbell commented 2 years ago

@Shyam-Gupta is the right contact from WinForms

CyrusNajmabadi commented 2 years ago

@Shyam-Gupta do you know what would cause:

[06:20:31.6217596] [WinFormsApp1]: Timed out while connecting to named pipe: DesignToolsServer.5d8b3c95-714f-4c62-91df-b0ad36c1f4dc

                   For information on how to troubleshoot the designer refer to the guide at https://aka.ms/winforms/designer/troubleshooting.
[06:20:31.6577714] Microsoft.DotNet.DesignTools.Client.ServerException: Timed out while connecting to named pipe.
                      at Microsoft.DotNet.DesignTools.Client.Host.ServerProcess.<ConnectToStreamAsync>d__35.MoveNext()

?

Shyam-Gupta commented 2 years ago

@CyrusNajmabadi It is a bit generic error. Its hard to guess the exact cause of the problem from the logs. I will debug to identify the root cause and get back soon.

FYI: @merriemcgaw

Shyam-Gupta commented 2 years ago

@CyrusNajmabadi, @merriemcgaw I couldn't repro the WinForms error logged in output window. As expected, WinForms dll having the relevant code doesn't even get loaded in this scenario. I checked with @AArnott also offline. This issue doesn't repro for him as well anymore.

CyrusNajmabadi commented 2 years ago

Closing out as not repro for anyone :)

Shyam-Gupta commented 2 years ago

Just to be clear, we couldn't repro the WinForms output window error: Timed out while connecting to named pipe..., but we could repro the incorrect intellisense suggestion for MainMenu type.

CyrusNajmabadi commented 2 years ago

Reactivating. However, what makes the intellisense suggestion incorrect? It says: But this type does not exist in .NET 6. It last existed in .NET Core 3.0.

We get this information from an index provided to us. Checking the index we are given, it says that's there's a MainMenu class in the assembly System.Windows.Forms. So we'd need that index to be updated to be accurate. Note: i don't think there's any facility for the index to state anything about which version of .net we are targetting. I think our presumption was always that .net would not be making breaking changes, so if a type was valid, it would continue to be valid. If that's no longer the case, the indexing side will have to rethink what it wants to do in that case.

AArnott commented 2 years ago

It says: But this type does not exist in .NET 6. It last existed in .NET Core 3.0.

What says that? That doesn't appear in the user experience, per my screenshot.

I think our presumption was always that .net would not be making breaking changes, so if a type was valid, it would continue to be valid. If that's no longer the case, the indexing side will have to rethink what it wants to do in that case.

That is certainly not true. .NET regularly removes types across major versions.

sharwell commented 2 years ago

The index was implemented with the assumption that if such a change occurred, it would be such an insignificantly-used type that no one would notice. And to date, that's generally held true.

The main point from @CyrusNajmabadi here is we're using information from a database that contains no semantic information. We have no way to represent a version constraint or know that we need to filter something out, since at the time of lookup nothing is referencing the System.Windows.Forms assembly.

AArnott commented 2 years ago

I get the engineering challenge that fixing this represents. I trust you to weigh the complexity of the fix against the customer value of fixing it and close the bug at your discretion.