Problem with Roslyn Source Generators Intellisense #50451
Comments
Dotnet-GitSync-Bot
added
Area-IDE
untriaged
jinujoseph
added
Concept-Continuous Improvement
Developer Community
|
Moving back to 16.9 as this may be a dupe of another 16.9 bug. |
|
+1 This happens to me as well ... source generator (SG) created code shows up in VS with squiggles and in error list ... but can navigate to and the build output is 'succeeded'. When I do actual have an error, I have to wade thru hundreds of SG/fake errors making it hard to actually find the real error. I also found I need to kick off the builds from the CLI as building in VS (while developing) does not reliably kick off the SG, even a clean/rebuild does not reliably kick off the SG inside of VS. That said ... this SG stuff is great ! |
|
Also hitting this. The types aren't available in intellisense, but the project builds using them. Can see the Generated files in the solution explorer. Running 16.9.2. |
|
After some further investigation, it seems like Resharper might be the culprit, for me. Suspended it and all the intellisense immediately updated correctly. Resharper Version: |
|
I also need to restart Visual Studio to be able to see my generated types in intellisense, and i don't have Resharper. Project builds correctly, and i can see all the generated sources in Solution Explorer. |
|
The solution posted here Mostly fixes the issue for me. However, this seems to trigger other IDE components crashing at times. Mostly I hope Microsoft has a proper way to address this soon. |
|
I'd close this as a dupe of #44093. Added more logs to that one today. |
Since several issues are open for source generators, making a custom target with an executable will be more reliable. dotnet/roslyn#50451
|
I'm having this issue with Visual Studio 2022 (17.0.0 preview 4.1, details below), however not with Visual Studio 16.9 (16.11.4, details below). I'm using a very slightly modified It's getting quite frustrating as I've quite a few of these, and it doesn't even recognise the
----
**Microsoft Visual Studio Community 2022 Preview**
Version 17.0.0 Preview 4.1
VisualStudio.17.Preview/17.0.0-pre.4.1+31717.71
Microsoft .NET Framework
Version 4.8.04161
Installed Version: Community Visual C++ 2022 00476-70000-00000-AA110 .NET Core Debugging with WSL 1.0 ADL Tools Service Provider 1.0 ASA Service Provider 1.0 ASP.NET and Web Tools 2019 17.0.616.20688 Azure App Service Tools v3.0.0 17.0.616.20688 Azure Data Lake Tools for Visual Studio 2.6.4000.0 Azure Functions and Web Jobs Tools 17.0.616.20688 Azure Stream Analytics Tools for Visual Studio 2.6.4000.0 C# Tools 4.0.0-4.21458.2+2bfff7b9348e779628a06b86af04b5239d3a926d Common Azure Tools 1.10 Fabric.DiagnosticEvents 1.0 Microsoft Azure Hive Query Language Service 2.6.4000.0 Microsoft Azure Service Fabric Tools for Visual Studio 17.0 Microsoft Azure Stream Analytics Language Service 2.6.4000.0 Microsoft Azure Tools for Visual Studio 2.9 Microsoft JVM Debugger 1.0 Microsoft Library Manager 2.1.134+45632ee938.RR Microsoft MI-Based Debugger 1.0 Microsoft Visual C++ Wizards 1.0 Microsoft Visual Studio Tools for Containers 1.2 Microsoft Visual Studio VC Package 1.0 NuGet Package Manager 6.0.0 ProjectServicesPackage Extension 1.0 Razor (ASP.NET Core) 17.0.0.2143108+3355b17aa26a41735ddf03b9fd3f71df166c0411 SQL Server Data Tools 17.0.62109.15100 Syntax Visualizer 1.0 ToolWindowHostedEditor 1.0 TypeScript Tools 17.0.0901.2001 Visual Basic Tools 4.0.0-4.21458.2+2bfff7b9348e779628a06b86af04b5239d3a926d Visual F# Tools 17.0.0-beta.21431.1+a7e1ca9200c21fd832dd9829fe1c655b69424ae8 Visual Studio Code Debug Adapter Host Package 1.0 Visual Studio Container Tools Extensions 1.0 Visual Studio IntelliCode 2.2 Visual Studio Tools for Containers 1.0
|
|
@LazerFX can you link us to repro commit of your source where you're seeing this? |
|
Have a reproducible example - problem occurs when using a WPF project targeting .NET 6 or .NET 5. It doesn't appear in a standard .NET Console or Application Library project targeting any platform I'm working with. MRE is at https://github.com/LazerFX/SourceGenRepro - this reliably fails to work for me. It also gives me a workaround for my current project, as I can create a class library to do the work, that then can be referenced in the WPF project. |
|
Thanks for that - I've done what I can to report this; tricky to notate and describe, but I've done my best and hopefully the telemetry will be useful. https://developercommunity.visualstudio.com/t/Source-Generators-that-create-partial-cl/1559682 |
|
I resolved my issue with intellisense completely. What I observed:
The root cause is that producer doesn't wait until previous invocation is finished or not. In my case the issue was that I shared a state of generation context in my generator, thus any unexpected invocation of gelegate leads to unexpected state. It is not clear how to understand in generator that new invokation is coming and we should stop previous one (I guess My solution is very simple, but it works (yeah, with lack of performance) class MyGenerator : IInrementalGenerator
{
void Initialize(...)
{
context.Register(... () => {
lock()
{
// produce output here
}
});
}
}I see my delegate is invoked and state of my generator is consistent, not broken by any others threads. PS: It's not a solution, it's just observation that delegate can be invoked at any time and even in parallel. Please don't treat it as a solution. |
|
@nvborisenko: A few things:
We don't have any "on save" behavior here -- even an ISourceGenerator will run more frequently.
Yep, that's what you need to be using here: generators absolutely must checking the cancellation token and aborting the generation if that's triggered.
OK if I edit your comment to make it in bold that this shouldn't be done? I worry somebody coming along, seeing your code, and doing that without seeing the PS. |
Oh yeah, definitely never ever do that :)
Yes, i would even go as far as removing/hiding this code. Locking this because you have shared mutable state that is getting corrupted is def not the way to go. Analyzers/Generators must absolutely not share mutable state (or state for that matter). The best thing to do is rearchitect to not have any sharing, and thus not have/need any locking. |
|
To address one thing in particular: lock()This would be super bad :) While it might prevent shared state corruption (see above on wanting to avoid that entirely), you'll now make it so that every thread that is running and producing compilations (which there are many) are now all blocked on the work of the one thread that can proceed. This means that it's easily possible to starve out teh entire threadpool, which will now slow down everything, possibly forcing the runtime to go into hill-climbing mode where it continually spawns threads to try to deal with this. Those threads will come in and block again, leading to just incredibly bad issues in the threadpool. In our experience we've seen such patterns end up with hundreds to thousands of threads spawned and blocked, just bringing everything to its knees. |
|
Guys, no problem at all to hide/delete my comment! But please let's improve documentatoin and highlight the way how (often/when) the delegate is invoked and what is happening with previous invokation. Just to avoid silly mistakes made by me. |
|
I'm running VS 2022 (version 17.5.2) and also have the same problem whereby intellisense is completely out of sync with source generated content. The build completes without errors, and I can navigate to the source generated, partial types, but Visual Studio is lit up like a Christmas tree with red squigglies everywhere. The solution builds cleanly, but reports ~1400 "errors", which really aren't errors at all. No amount of closing/restarting Visual Studio, cleaning, deleting the I have the "Display diagnostics inline (experimental)" setting turned on, because I generally like the immediate/obvious feedback that provides, but its value is diminished because of all the "noise"/false error reporting. A fix for this would be greatly appreciated, because source generators are awesome! I see that this was first reported over 2 years ago now. Any indication if/when this will get prioritized as a bug to fix? Thank you. |
|
@prlcutting We fix bugs as we can get usable reports, unfortunately there's any number of things that can cause the same symptoms, including problems in the generators themselves. So alas there's not "one bug to fix", and then tend to have difficult or inconsistent repros. If you're in that state, and are able to create a memory dump of the devenv.exe and Roslyn ServiceHub process, we might be able to spelunk through that and see if we can get some hints what the problem may be. |
|
@jasonmalinowski - thanks for quick response. I fully understand and sympathize with the challenge you face chasing down bug reports with limited information. I'll see if this is something I can create a small repro of (obviously can't share our commercial IP), or a memory dump as you suggest. Is there any risk that a memory dump could disclose proprietary information? You suggested that problems in the generators themselves could cause the symptoms we're seeing. Can you please provide further guidance/advice or point me to any documentation on specific things I should be looking for to make sure we're doing it correctly. Thanks again. |
Yes. Memory dumps will contain all the information in the VS process memory space, which may include proprietary information. However, we would be required to follow all our rules about privacy, data collection, data retention, etc. I would recommend reporting the dump using VS's 'Report a Problem' side:
This will ensure that it can only go through if it meets your org's rules they have set up on your side, and will then go through our own system that has all these protections in place as well. |
|
I have a project that I can consistently reproduce this error in, https://github.com/MeltyPlayer/FinModelUtility. I've filed a ticket with diagnostic reports, hopefully this helps: https://developercommunity.visualstudio.com/t/Intellisense-does-not-recognize-interfac/10328977 |
|
Just following up on this. Apologies in advance for the lack of concrete, actionable information, but just wanted to let you know that the problem persisted for me for a while, but after a reboot a few days later (no idea if that was the "fix"), the problem went away (for the same code base). As previously mentioned, no amount of closing/restarting Visual Studio, cleaning, deleting the |
|
The workaround that seems to work for me is putting the following in the consuming csproj file: This will emit the generated files into a folder Note: you'll probably want to put the |
|
@arkalyanms the release 17.5 is already passed. See: https://devblogs.microsoft.com/visualstudio/visual-studio-2022-17-5-released/ |
Yes that is why I removed the 17.5 milestone tag as a part of cleaning up some of our older milestone targeting items. |
This issue has been moved from a ticket on Developer Community.
[severity:It bothers me. A fix would be nice]
In the attached project SourceGenBugApp.zip, if you start with a clean solution, open Program.cs in SourceGenBugApp project:
Original Comments
Feedback Bot on 11/11/2020, 00:25 AM:
We have directed your feedback to the appropriate engineering team for further evaluation. The team will review the feedback and notify you about the next steps.
Feedback Bot on 11/11/2020, 09:49 AM:
This issue is currently being investigated. Our team will get back to you if either more information is needed, a workaround is available, or the issue is resolved.
Original Solutions
(no solutions)
The text was updated successfully, but these errors were encountered: