Open AArnott opened 2 years ago
@genlu Would this situation be triggered by this option?
These crashes seem to be in: Microsoft.VisualStudio.WinForms.ProjectWatchers
@DustinCampbell do you know who might be able to help out here?
@Shyam-Gupta is the right contact from WinForms
@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()
?
@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
@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.
Closing out as not repro for anyone :)
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.
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.
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.
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.
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.
Version Used: Dev 17.2 Preview 3 (32330.571.main)
Steps to Reproduce:
MainMenu
.Expected Behavior:
Nothing offered.
Actual Behavior:
Completion for a Windows Forms type is offered:
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: