jasonmalinowski
commented
3 years ago Moving back to 16.9 as this may be a dupe of another 16.9 bug.
Open vsfeedback opened 3 years ago
jasonmalinowski
commented
3 years ago Moving back to 16.9 as this may be a dupe of another 16.9 bug.
aktxyz
commented
3 years ago +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 !
adstep
commented
3 years ago 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.
adstep
commented
3 years ago 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:
Visual Studio: 16.9.2
thomas-girotto
commented
3 years ago 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. I'm using VS 16.9.2.
BMagerMT
commented
3 years ago The solution posted here https://github.com/dotnet/roslyn/issues/44093
Mostly fixes the issue for me.
<PropertyGroup>
<EmitCompilerGeneratedFiles>true</EmitCompilerGeneratedFiles>
<CompilerGeneratedFilesOutputPath>Generated</CompilerGeneratedFilesOutputPath>
</PropertyGroup>
<Target Name="AddSourceGeneratedFiles" AfterTargets="CoreCompile">
<ItemGroup>
<Compile Include="Generated\**" />
</ItemGroup>
</Target>
<Target Name="RemoveSourceGeneratedFiles" BeforeTargets="CoreCompile">
<ItemGroup>
<Compile Remove="Generated\**" />
</ItemGroup>
</Target>However, this seems to trigger other IDE components crashing at times. Mostly I hope Microsoft has a proper way to address this soon.
kzu
commented
3 years ago I'd close this as a dupe of #44093. Added more logs to that one today.
LazerFX
commented
3 years ago 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 AutoNotify from the default samples, which creates an INotifyPropertyChanged partial class with public Properties that update the private Fields in the class I write, together with a PropertyChangedEventHandler and all wiring up.
It's getting quite frustrating as I've quite a few of these, and it doesn't even recognise the [AutoNotify] attribute as existing. I can clear Intellisense, wipe the .suo and .vs files and folders, build in 2019 and open in 2022, and it won't stay 'working' beyond any change to the classes modified or any inheritance from them.
CyrusNajmabadi
commented
3 years ago @LazerFX can you link us to repro commit of your source where you're seeing this?
LazerFX
commented
3 years ago 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.
LazerFX
commented
3 years ago I can confirm that it appears that switching the AutoNotify property to a class library project appears to have resolved the issue, at a bit of effort refactoring and such.
LazerFX
commented
3 years ago I will say that even with this change, the Source Generator Intellisense support is very flaky. It likes to fall over, and when it does the only thing that will restart it is a restart of the IDE.
One cause that's almost guaranteed to crash it are changes to the source objects that are sourcegenerated, causing new properties to be added or removed. However, even in that instance, if you've multiple objects that rely on the same source generator, ALL of them will be taken out at the same time.
Another cause that occasionally causes it to crash is tabbing too quickly through autocompletion options when referencing generated properties.
jasonmalinowski
commented
3 years ago If folks are seeing crashes, please do send feedback reports by going Help menu > Send Feedback > Report a Problem. There's one fix that we shipped in 17.0 Preview 6 and we're looking at one other one right now, so more reports would be appreciated.
LazerFX
commented
3 years ago 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
nvborisenko
commented
2 years ago I resolved my issue with intellisense completely.
What I observed:
ISourceGenerator interface, you specify a delegate somewhere in your class. And this delegate is invoked each time when user saves a file under interest.IIncrementalGenerator, then your delegate will be invoked as soon as user types in a file under interest.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 context.CancellationToken helps here, but I didn't test it).
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.
My generator makes new classes based on AdditionalFiles.
jasonmalinowski
commented
2 years ago @nvborisenko: A few things:
And this delegate [for ISourceGenerator] is invoked each time when user saves a file under interest.
We don't have any "on save" behavior here -- even an ISourceGenerator will run more frequently.
It is not clear how to understand in generator that new invokation is coming and we should stop previous one (I guess context.CancellationToken helps here, but I didn't test it).
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.
Please don't treat it as a solution.
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.
CyrusNajmabadi
commented
2 years ago 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
Oh yeah, definitely never ever do that :)
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.
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.
CyrusNajmabadi
commented
2 years ago 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.
nvborisenko
commented
2 years ago 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.
prlcutting
commented
1 year ago 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 .vs folder or anything ever makes the errors go away.
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.
jasonmalinowski
commented
1 year ago @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.
prlcutting
commented
1 year ago @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.
CyrusNajmabadi
commented
1 year ago Is there any risk that a memory dump could disclose proprietary information?
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.
MeltyPlayer
commented
1 year ago 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
prlcutting
commented
1 year ago 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 .vs folder or anything else would make the errors go away.
chtenb
commented
1 year ago The workaround that seems to work for me is putting the following in the consuming csproj file:
<PropertyGroup>
<EmitCompilerGeneratedFiles>true</EmitCompilerGeneratedFiles>
<CompilerGeneratedFilesOutputPath>$(ProjectDir)Generated</CompilerGeneratedFilesOutputPath>
</PropertyGroup>
<Target Name="SkipSourceGeneratedFiles" BeforeTargets="CoreCompile">
<ItemGroup>
<Compile Remove="Generated/**/*" />
</ItemGroup>
</Target>This will emit the generated files into a folder Generated/ in your project tree, which makes it look like normal source code for Visual Studio. This makes the IntelliSense work. However, since the sourcegenerators are still invoked at compile time, we need to skip the generated files from the project tree when compiling, which is what the SkipSourceGeneratedFiles target does. Credits to https://github.com/dotnet/roslyn/issues/44093#issuecomment-626248357
Note: you'll probably want to put the Generated folder in your .gitignore file.
Pupka-Lipinski
commented
1 year ago @arkalyanms the release 17.5 is already passed. See: https://devblogs.microsoft.com/visualstudio/visual-studio-2022-17-5-released/
arunchndr
commented
1 year ago @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)