Sticky IntelliSense errors when opening uncompiled solution using NuGet library

[BentTranberg]

When an existing F# .NET Framework solution using NuGet libraries is opened and compiled in VS 2017, and there are no bin, obj and packages folders, then there will be IntelliSense errors that won't go away until you restart VS.

Repro steps

Fast repro steps, using attached project in zip file

1. Unzip the attached repro. (Remember to unblock the zip file first.)

2. Open the solution, and wait a few seconds. You should see errors in the Error List pane. If not, try to compile.

The solution has no errors, and compiles successfully. The reported errors are from IntelliSense.

Solution files here:
BugHunt3b.zip

====

Alternative repro steps, doing everything from scratch.

1. Create a solution and a new F# console project.

2. Include a NuGet project. I have tested with FsXaml and with Gjallarhorn, in two separate repros. This I believe indicates that it is not related to type providers, since as far as I know Gjallarhorn does not contain a type provider.

3. Insert "open FsXaml" or "open Gjallarhorn".
   3b. Suggest you also use something from the library, so you can get more errors. See screenshot.

4. Compile. This does not provoke illegitimate errors.

5. Close Visual Studio.

6. Delete the bin and obj and packages folders.

7. Reopen Visual Studio and solution.

You should see errors after a few seconds. If not, try to compile.

Known workarounds

The sticky errors will go away if VS is restarted.

Related information

Visual Studio 2017, 15.3.2.
Visual F# Tools, Nightly 15.4.1.17082301.
Project created with .NET Framework 4.5.2 or 4.6.1.

Reproduced on two machines.

Severity: Not critical. Easy workaround.

[BentTranberg]

A screenshot from my production solution shows that not just FS0039 is reported by IntelliSense in connection with this issue. Also in this case, the solution compiles successfully.

[dsyme]

@BentTranberg Thanks for providing such an excellent step-by-step repro, this will make it much easier to track this down

[dsyme]

(Note this is still dealing with the enormously long bug trail from the Roslynization effort this time last year.... AFAIK this sort of thing works correctly in VS2015)

[BentTranberg]

This issue appears to have been fixed at some point between August 2017 and today. I am not able to reproduce it with Visual Studio 15.5.1 and the repro. Do we close it, @dsyme ?

[cartermp]

I can still reproduce this on 15.6 Preview 1 after building the project, so it is indeed a regression from VS 2015.

However, if I create a new project like this for .NET Core, everything works. So I suspect it's either an issue in our legacy project system or the language service hookups. Note that for .NET Core, Gjallarhorn is restored for a .NET Framework target, so there will still be a NuGet warning. But the symbols from the assembly are shown.

[wanton7]

I have this problem with project created with "dotnet new giraffe" and it's a .NET Core project. It's giving me three "F0039 The namespace 'AspNetCore' is not defined" errors.
Project builds fine but those errors are sticking to Error List window. I'm using Visual Studio 15.5.3,

[cartermp]

@wanton7 I suspect what you're seeing is #3952 instead. If you close and re-open the file, does the error go away?

[wanton7]

@cartermp you are right, errors go away when I close Program.fs. Must be #3952 then.

[BentTranberg]

Long time no see. But today I ran into this again. And now it's VS 15.7.3.

I suspect I have been running into it regularly, but normally just haven't got time to brood over irregularities like this unless they actually cause trouble for me. (edit: Just to be clear, it's not causing me trouble.)

The project this time uses PAKET which I haven't used before, but I guess that isn't a piece of the puzzle at all. Other than that, the situation seems to be exactly as I described the first time.

[BentTranberg]

I've been bothered more and more with sticky errors (and warnings) in VS 2017 lately. The reason seems to be that I recently introduced one library with a type provider, and that library is FSharp.Configuration and its YAML type provider.

I almost did not have type providers at all in the solution before this (edit: for many months) - only FsXaml in some projects that I've barely touched for a long time, though they are compiled. That probably caused the few occurrences of this problem that I noticed now and then.

The behavior described at the very top is confirmed. But more than that, illegitimate errors now flood the error pane quite frequently, also when packages and obj and bin are in place.

Also note, I've started migrating libraries from Framework to Standard 2.0. However, I doubt this is relevant. The type provider and its use have not been migrated to Standard.

The workaround is simple as always - change to "Build Only" in the Error List. / edit: Also restarting VS helps.

edit 29th Aug '18: Got FS0039 from IntelliSense when compiling with a new field added to the YAML. The VS version is 15.8.1.
edit 3rd Sep '18: Still there, but now very rare, so definitely not a problem.

[jackfoxy]

I hope this gets worked soon. I recently submitted a similar issue which got marked as a duplicate of this one. If this is truly my issue, it is my #1 issue with VS 2019 16.3.0 Preview 2.

[BentTranberg]

Retested on 2nd Sep 2020. Issue present in VS 16.7.2 and VS 16.8.0 Preview 2.1

Also note the similarities with #8760. Possibly same root cause, and both have solid repros.

[BentTranberg]

I suspect this has been fixed.

I am able to reproduce the problem in VS 16.10.4

I am not able to reproduce the problem in VS 17.0.0 Preview 2.0

When trying to reproduce the problem, I did so using the solution in the zip-file.

I also tried to reproduce the problem by creating .NET 5 and .NET 6 F# projects from scratch in the two VS versions, and using FsPickler from NuGet, since Gjallarhorn and FsXaml are .NET Framework only. No problems observed. I don't think Gjallarhorn is a type provider, so using FsPickler is likely just as good for provoking a possible problem.

Anyway, this report is about a problem with a .NET Framework project using the old project format, so if that's really fixed, which it seems to be, perhaps close, or... ? (We've been here before, so I dare not put money on it.)

[dsyme]

Closing per @BentTranberg report that this has ben fixed