F# compile errors appear as "IntelliSense", not as "Build", in Error List pane of VS 2017

[BentTranberg]

In order to see F# compiler errors, I have to select "Build + IntelliSense" in the Error List pane of VS 2017.

Why isn't output from the F# compilation for the build visible when only "Build" is selected in the Error List pane?

When compilation is finished, there are lots and lots of errors in the Error List pane, coming from IntelliSense. There are also error squiggles in the source, from IntelliSense. This in spite of the Output pane reporting a successful build with no errors.

Repro steps

Compile a simple F# test project in VS 2017. Toggle the setting between "Build" and "Build + IntelliSense" in the Error List pane, and watch what happens while editing and compiling with and without errors in the source.

Expected behavior

Errors from the F# compiler should be visible in the Error List pane when "Build" is selected.

F# IntelliSense shouldn't flood the Error List pane with all sorts of normal compiler errors.

Actual behavior

Errors relating to F# is only visible when "Build + IntelliSense" is selected in the Error List pane, and the pane behaves in a way that indicates that IntelliSense is at work, independently from the build compilation.

F# compilation can report a successful build in the Output pane, while there are errors listed by IntelliSense in the Error List pane.

F# compilation can report errors in the Output pane, while the Error Pane lists 0 errors for the entire solution.

Known workarounds

No known workaround that makes it practical for me to work continuously in VS 2017 with a large solution with a mix of C# and F# projects. Have to rely on VS 2015 as backup until this is solved.

Related information

Provide any related information

F# 4.0 (4.4.0.0)

• Operating system : Windows 10
• .NET Runtime, CoreCLR or Mono Version : .NET Framework 4.5.2
• Editing Tools (e.g. Visual Studio Version) : VS 2017 first release

[vasily-kirichenko]

What the errors shown in the editor as red squiggles say?

[BentTranberg]

They are the normal errors I would expect if I had left my original error in the source, but they persist in the Error List pane even after the actual error is removed again.

But I have found a couple of things that I think can give a clue.

When I close the source window, and reopen, the intellisense starts to work, and the error list changes. The errors appear in all F# projects - even in projects that doesn't depend on the project where the error is, which is a unit test project, and so a top level project within the solution.

More importantly, there are these warnings, which are unusual. They occur only in the F# projects in the solution (seems very natural of course), but is reported an unequal number of times for each F# project.

Warning AD0001 Analyzer 'Microsoft.VisualStudio.FSharp.Editor.FSharpDocumentDiagnosticAnalyzer' threw an exception of type 'System.Threading.Tasks.TaskCanceledException' with message 'A task was canceled.'.

I didn't notice these until now, because they were drowning in "legacy warnings" in the project, which I will clean up eventually.

[vasily-kirichenko]

It's almost certainly fixed in current master. I recommend to install fresh VSIX when Microsoft provide it (I hope very soon, maybe today).

[BentTranberg]

Thanks, will do, and report back.

[vasily-kirichenko]

It looks like the vsix is already there https://github.com/Microsoft/visualfsharp/wiki/Using-CI-Builds

[BentTranberg]

Getting a bit off-topic now, but I promised feedback. I can't confirm whether the vsix fixed the problem or not, since I can't get it installed and working properly. The following is just FYI, and I understand I can't expect help solving that issue here.

I believe I followed the installation instructions to the letter. Have tried three times. After installation, when trying to open solutions with F# projects, I get an error dialog about not being able to load the extension, and it refers to a log file (xml) with this error message at the end. In Solution Explorer, the F# projects are all listed as "TheProjectName (incompatible)".

CreateInstance failed for package [FSharpProjectPackage]Source: 'mscorlib' Description: Could not load file or assembly 'FSharp.ProjectSystem.FSharp, Version=15.4.1.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. Strong name validation failed. (and stack trace follows)

I did run the two "sn" commands during installation, and they succeeded.

Maybe I'll just wait until this comes into VS 2017 via regular updates. Not a problem for me in the short term.

[0x53A]

@BentTranberg you mention running TWO sn commands - but the second command re-enables strong name validation =)

To use the VSIX you need to run the FIRST command. This will leave your machine in an "insecure" state (I don't think there is actually an attack vector), so if you want to re-enable it, you can do that with the second command, but then the vsix will stop working.

[BentTranberg]

Woops! Thank you very much for clarifying that.

I think I was just touching that thought while typing the command, but obviously didn't hold on to it long enough to try it later. This is unfamiliar territory to me. I also think the documentation on that page is very easy to misunderstand on that point. It's written so that turning it back on looks like the final step of the procedure. It should say e.g. "if you later want to ..."

Visual Studio now crashes when trying to load the solutions with F#, so I still can't verify whether the vsix will fix the issue if only it runs. I'll come back here later and tell if I do find out.

[KevinRansom]

master branch seems to have the same problem.

This report is a duplicate of : https://github.com/Microsoft/visualfsharp/issues/2547

[BentTranberg]

The installation instructions for the VSIX on the "Using-CI-Builds" page changed, and I finally managed to get things working. Thanks for that. I don't know how you identify it, but the vsix file I use now, has a creation stamp of 8th March 18:37.

NEW STATUS

The Error List pane no longer has frenetic activity ("lots and lots of errors"), and there are no longer "squiggles everywhere" in the source, when loading a large solution with several C# and F# projects. This makes it possible for me to use VS 2017 a lot more. Thank you.

However, F# compile errors are still not visible in the Error List pane, not even after a compile, when the pane is set to "Build" only. ( For comparison, C# compile errors do show up, and C# intellisense errors do not show up, so everything is ok with that one.)

[vasily-kirichenko]

I'm not sure how build errors should find their way to Errors List window, but our project-wide diagnostics analyzer is disabled because we cannot make it to work properly (it's a long story).

[BentTranberg]

I did a little study of how things behave in the Error List pane in VS 2015 versus 2017. Based on that, I have this theory of what might have happened.

C#, 2015, Build : only updated when you explicitly build. OK C#, 2015, IntelliSense : continuously updates as you edit. OK F#, 2015, Build : continuously updates as you edit. Uhm .. sort of OK F#, 2015, IntelliSense : receives nothing.

So there is a problem even in VS 2015, but for all practical purposes, stuff works quite well. The F# "Build" errors are actually reported by continuous analysis, and not explicit compile. It explains why F# errors seem to come and go and come back again, but it didn't bother people that much. If you think about it, it makes sense.

C#, 2017, Build : only updated when you explicitly build. OK C#, 2017, IntelliSense : continuously updates as you edit. OK F#, 2017, Build : receives nothing. F#, 2017, IntelliSense : continuously updates as you edit.

Speculation: I am thinking somebody noticed that (in VS 2015) output from continuous analysis (IntelliSense) was directed to "Build", and thought "hey, that doesn't make sense", and directed it to "IntelliSense" instead. That would be understandable, but rather unfortunate.

If this is what happened, then my suggestion is to look for a minor change between VS 2015 and 2017 that only involved changing the output from "Build" to "IntelliSense", and then revert that change to improve the situation. Later, a more proper solution can be implemented. An alternative is to make it configurable for now, so that the situation can be salvaged for those of us that suffer from this change.

Why: If you only investigate this with small sample solutions, you may not grasp what's so bad about the change. If you are used to working with "Build" to prevent a flood of messages when working on larger solutions (25+ projects), then in VS 2017 you now have to continuously switch between using "Build" for C# and "IntelliSense" for F#, while filtering with "Current Project" instead of "Entire Solution" so that F# messages can be seen without noise from C# IntelliSense. Huge practical problem that slows you down. Nobody suffered the way it was.

[BentTranberg]

The situation has been hugely improved since my last feedback, and there is no longer any practical problem whatsoever due to this issue, at least for me. I am working on a large project with a mix of C# and F#. The practical problems was caused by this issue in combination with other issues that has now been fixed.

The F# compiler no longer floods the Error List pane with errors, but keep the count quite low, and targets the actual problems in the source very well. The reaction from the compiler is also very fast, and stays quite stable. VS 2017 with F# now delivers a better user experience than VS 2015 for me.

Visual F# Tools 15.4.1.17032701, and VS 2017 15.0.0+26228.10.

The issue still remains, that F# compiler output is exclusively to Intellisense in the Error List pane, as opposed to C# that outputs to Intellisense continuously and to Build when doing a build. Maybe somebody should say something about whether or not this behavior is as it should be.

I suggest this issue either the closed, or set to lowest priority.

[cartermp]

@BentTranberg I updated this with the following labels and set the milestone to VS 2017 Updates. This could end up getting fixed incidentally through various minor fixes which come in over time. I'm happy that the nightlies seem to make this problem far less severe, though.

[saul]

It's worth pointing out that build errors do not show in the "Build + IntelliSense" window. The only errors that show there are IntelliSense errors.

Build-only errors such as: FSC: error FS0084: Assembly reference 'E:\Code\DevTools\libs\Foo\bin\Debug\Foo.dll' was not found or is invalid do not show in the Error List window whatsoever.

Does anyone on the Roslyn side know how build errors are hooked upto the Error List window? @CyrusNajmabadi? :)

[dsyme]

Build-only errors such as: FSC: error FS0084: Assembly reference 'E:\Code\DevTools\libs\Foo\bin\Debug\Foo.dll' was not found or is invalid do not show in the Error List window

So that's a regression then?

[CyrusNajmabadi]

Sorry, i'm unfamiliar with thsi part of Roslyn. @heejaechang or @mavasani might know though.

[saul]

Yes @dsyme it's definitely a regression

[mavasani]

@heejaechang knows about the de-duping logic with Build and Build + Intellisense, though he is OOF this week.

[saul]

Thanks for the quick response @CyrusNajmabadi - I'll try paging @heejaechang next week.

Also for one of the F# team - can we remove the 'Flaky' tag from this and put in Bug and/or Regression?

[saul]

Okay I've got a fix locally. It looks like we're trying to grab SOleComponentManager too soon and it's returning null. I've copied what PTVS is doing and I've got the Error List to work again. Will open a PR in a day or so 👍