Thousands of phantom IntelliSense errors on VS 2026

[jwdawe]

.NET Framework solution builds & runs successfully, while the error list on VS-2026 shows tens of thousands of false errors. The IDE believes they are real and Goto Definition/Implementation/Base, refactor tooling, the editor squigglies, Find all References, etc. believe they are real and are broken accordingly. The issue was not present on VS 2022, yet I don't see many complaints about this on VS 2026?

My original reports were here -

https://developercommunity.visualstudio.com/t/Thousands-of-phantom-IntelliSense-errors/11014463

Some similar but not quite identical are

https://developercommunity.visualstudio.com/t/Intellisense-no-longer-working/11005448
https://developercommunity.visualstudio.com/t/Go-to-definition-or-implementation-not/11005168

I have one branch targetting .NET (framework) 3.5, the other 4.8, is the same on both sides.

Many of these reports seemed to get referred here so I figured I'd put it in with the links. Started sometime in Sept/Oct during the Insiders phase and persisted into the VS-2026 release

[CyrusNajmabadi]

Maybe something in the project system breaking, and not giving us teh right corlib references.

[CyrusNajmabadi]

@jasonmalinowski i feel ike we've been getting a few reports of incorrect references in the project system in a few ways. Either p2p refs breaking, or metarefs not coming in. Does this tickle anything in your brain?

[jasonmalinowski]

This would be the first I've heard of any recent issues. Obviously these types of issues aren't new, but not aware of widespread problems at the moment.

@jwdawe if you could follow the instructions at https://github.com/dotnet/project-system/blob/main/docs/design-time-builds.md#diagnosing-design-time-builds that would be a great place to start. If you're unsure about how to analyze the logs, feel free to upload them to the feedback ticket you created and we can take a look. I've assigned that ticket to me internally.

[jwdawe]

Attached to the dev. community ticket. On .NET 4.8 running w/ set MSBUILDDEBUGENGINE=1 actually seemed to help; on .NET 3.5 it was the same. Everything seemed OK opening with the log viewer. I checked again on the same solution and it's OK on VS-2022; that would be viable workaround though I like the new release.

Often project-by-project you can work-around it by removing a project reference then re-adding it; seems to refresh something? The *.csproj are in the non-SDK legacy format :/

[jwdawe]

Hello, something linked from design-time-builds.md mentioned a whitespace edit to *.csproj will force it to reload. It turns out this is a viable work-around,

With the solution open in VS when getting the issue you can run something like this in solution root

reload-csproj.ps1
Get-ChildItem -Path "." -Filter '*.csproj' -Recurse | ForEach-Object { (Get-Content $_.FullName) -replace '</Project>', '</Project> ' | Set-Content $_.FullName }

or similar to add some whitespace to all csproj in the tree.

Then hit Reload All when Visual Studio prompts, the editor and error list errors drop to 0 and the IDE works normally.

[jasonmalinowski]

Hello, something linked from design-time-builds.md mentioned a whitespace edit to *.csproj will force it to reload. It turns out this is a viable work-around,

Ah, so once you touch all the files then that refreshes nicely? Were the logs you took here from that refreshing process or the first run?

[AdmiralSnyder]

here's another issue i just filed, describing the same problem, probably.
https://developercommunity.visualstudio.com/t/VS2026:-Phantom-errors-show-up-after-sol/11026106?port=1026&fsid=1bd26cb4-8a3b-4235-9d29-da6c239c4dc5
i have net48 projects and net10.0 ones, plus some netstandard and some multitargeting net48 and net10.0 - we've been doing the big jump a couple days a go -
it feels to me as if the errors (at least some of them) occur because source code emitted by source generators isn't seen.

to mitigate that, we use the "Project Filter" extension to unload all projects quickly (with 3 clicks) after each VS restart, and then reload all of them from the solution's context menu - it's annoying nonetheless, though.

[jwdawe]

Hello, something linked from design-time-builds.md mentioned a whitespace edit to *.csproj will force it to reload. It turns out this is a viable work-around,

Ah, so once you touch all the files then that refreshes nicely? Were the logs you took here from that refreshing process or the first run?

They were from the first run rather than the refresh trick. I'm grateful to know about set MSBUILDDEBUGENGINE=1, the MSBuild Log Viewer, and design-time builds, thank you for that.

Trying to capture the issue with the msbuild logging since though, I can reproduce the issue but when you look at the captured logs as far as I can tell everything seems OK!

Sometimes it will temporarily show errors such as

CS0518 Predefined type 'System.Object' is not defined or imported
CS0518 Predefined type 'System.Boolean' is not defined or imported
CS0518 Predefined type 'System.Void' is not defined or imported

These CS0518 tend to disappear on their own 1-2 minutes later, and only on initial solution open on a fresh checkout or full revert & cleanup. Maybe that is normal and unrelated? I have no idea..

The sequence seems to be do the initial solution load on a fresh or freshly-cleaned checkout, then switch do another solution config (e.g. ARDebug|x64 to NTDebug|x64), then there are lots of false errors the seem to clear up over time or if you touch all the *.csproj to force a reload like that.

Looking at #81844 the bot linked or @AdmiralSnyder's report, both mention VS-2026 and .NET Framework. I'm not sure whether they are also on the legacy *.csproj format or the SDK-style ones?

Sorry, I'd like a small sample solution that reproduces the issue but haven't been able to do that so far! Initially I had clicked 'I’m unable to use this version', that was before realizing how to work around it. thx again!

[jwdawe]

Actually just got it on a completely different solution, the sequence was initial open the solution in VS-2026 with no untracked/no ignored files, only what is on the repo, no .vs no build output, then change solution configuration, here it was from Debug to Release, the false errors only appear after changing solution config

[jasonmalinowski]

Trying to capture the issue with the msbuild logging since though, I can reproduce the issue but when you look at the captured logs as far as I can tell everything seems OK!

If you're not seeing errors, the next thing to check would the Csc invocation. How a design time build works (roughly) is it runs the Csc build task that would normally invoke the compiler, but instead of actually running the compiler there's an option that makes the task just emit the command line string that would go to the compiler. That then gets consumed into the project system to get the list of references to us. So one thing to check would be if the set of references being given to the compiler looks right. For example do you have a System.Runtime or mscorlib or whatever being passed.

These CS0518 tend to disappear on their own 1-2 minutes later, and only on initial solution open on a fresh checkout or full revert & cleanup. Maybe that is normal and unrelated?

This could also be a side effect if your design time builds take a long time. The project system will first grab an MSBuild evaluation and pass what data it can pass over, which might just be source files and no references. Then once the design time build is done we'll get references. There's a mechanism in place where between that window where we have source files but not references we're supposed to suppress some errors because of things like this, but maybe that's not kicking in the way we expect.

Are your design time builds long? i.e. if they take a second or two that's fine. I know I've seen folks that have customized their MSBuild didn't realize that they might have been doing some really expensive stuff in there too.

[jwdawe]

*_DesignTimeBatchBuild_0.binlog on two different configs, the node just under Build Succeeded shows Duration = 36.819 s and Duration = 26.359 s respectively. On a completely different solution I got the issue for the first time (initial solution load then swtich debug to release config) it shows Duration = 20.4 s.

Definitely longer than 1-2 seconds if I'm looking at the right thing! Drilling into timeline etc. seems somewhat faster, on the larger solution, top most expensive task says "MarkupCompilePass1", about 6 secs, something to do with codegen and .baml gen for WPF and XAML?

CS0518 disappears consistently if you wait, probably not long after the design-time build is finished

For the csc command I looked around under Target CoreCompile on a few targets, you can see the csc params and everything, at first glance the references seem OK, mscorlib.dll, System.dll, anything I would expect are present! That's not to say everything is OK just do not spot anything amiss yet

On the smaller solution the fake errors after switching configs do not happen if the MSBUILD logging is on :/

[AdmiralSnyder]

we have sdk style csproj, all over, a complete design time build of the solution (amost 200 projects) takes 2:40 minutes.
yet, the errors do not go away by themselves, you need to manually touch (multiple) .csproj files

i also noticed that after we do the reloading-all-projects, errors don't show up as squiggles anymore in the editor - no idea if that's a separate problem or connected.