F# Language Services don't start when visible document at startup is a C# file

[ricksladkey]

Revised description of issue:

As far as I can tell, it is not correct (at least for the symptoms I am reporting) that F# Language Services "stop working". In fact, they never start and it is 100% reliable (for me) that if the active document in Visual Studio when it opens is a C# file, F# Language Services never start. I have to switch the active document to a F# file, close Visual Studio, and re-open the (VsVim) solution and then both F# and C# Language services work properly.

---

Original description of issue:

The problem is basically that F# Language Services simply stop working and don't come back.

Repro steps

1. Clone https://github.com/jaredpar/VsVim and open VsVim.sln in Visual Studio 2017

2. Start coding, e.g.

3. Checkout several different branches in succession "from underneath Visual Studio" while the solution is open (but it is not entirely clear what triggers the behavior)

4. At some point, all advanced F# language services stop working entirely with no messages: no type inference, no advanced syntax coloring (e.g. no colored module names or mutable variables, goto definition fails, etc.), nothing but comments and keywords remain with syntax coloration.

Expected behavior

Language services eventually become available after, e.g., changing branches.

Actual behavior

Usually it takes about 15 seconds of background language service activity before advanced F# language services become available. However, in the broken state, no matter how long you wait, the language services never comes back.

Known workarounds

Only closing and re-opening the solution and waiting the requisite 15 seconds will fix it.

Related information

• Windows 7, Version 6.1 (Build 7601: SP1)
• Visual Studio 15.7.3
• Microsoft Visual F# Tools 10.1 for F# 4.1, 15.7.0.0

[abelbraaksma]

Thanks for this. @cartermp and I and some others have tried a repro with my own solution. I have come to understand from @dsyme that after a certain timeout or high memory threshold the language services stop. But they don't reset.

[dsyme]

@ricksladkey Thanks for the repro, we'll take a look.

Does turning off in-memory cross-project references help?

I have come to understand from @dsyme that after a certain timeout or high memory threshold the language services stop.

This is not quite accurate. High memory usage degrades the tools but there is no known cause of them to "stop". If they are perceived to stop while VS continues to function otherwise then we'd consider that a bug, though we always need a repro to be able to make any progress with it.

[chillitom]

I saw this once when switching branches that use the old project file format and others that use the new format, could that be the case here?

[dsyme]

@chillitom I could absolutely imagine that would confuse the tooling greatly

[Pilchie]

Indeed - that's been a real pain point. When switching, please delete your bin and obj directories, as otherwise parts of the tooling will detect files there and do the wrong thing.

[ricksladkey]

@dsyme I failed to mention that I already have in-memory cross-project references turned off because the performance was so bad. With it turned on, intellisense for a single identifier used to take up to ten seconds to come up.

[ricksladkey]

@chillitom All the branches that I use daily (and seem to trigger the problem), are "recent" ones, and the project files themselves are unchanged between the branches.

[ricksladkey]

It does not seem to be related to memory use, because it is broken right now and Visual Studio is using "only" 458M, whereas it is routinely over 1.5G. On the other hand, it is pleasantly using no CPU, so that is a side benefit!

[cartermp]

@ricksladkey Re this:

With it turned on, intellisense for a single identifier used to take up to ten seconds to come up.

Which version is this exhibited? This was the case in older versions of VS (15.5), but with 15.7.3 I'd be quite surprised if you still saw this.

The only thing I could think of (as per comments here) is that checking out branches where the project file format changes (and thus the project system changes) results in a deaded language service. The new project system can handle these changes in the editor, but switching from that to the old one likely cannot.

[ricksladkey]

@cartermp It's very possible that the version I had trouble with in-memory cross-project references was 15.5.x or 15.6.x.

As a test, I've turned in-memory cross-project references back on and I'm not seeing the pathological slowness that caused me to turn it off. I'll test further with this setting, but I can already tell you that the "stops working" problem is still present.

[ricksladkey]

I think I found a repro for the F# stopping working problem. In fact, I can cause the problem without changing branches or changing any files or projects at all.

All I have to do is close Visual Studio with the selected document being a C# file associated one of the non-F# projects in the solution. If I then reopen Visual Studio, that C# file will be the first document window displayed. If I then switch windows to a F# file from an F# project, the F# language services never "start up".

It's true that I have many dozens of lazy loaded documents from previous editing sessions. Anyway, the workaround if that is true is to make sure an F# file is the active window when closing Visual Studio. I'll test that theory.

[ricksladkey]

Since the repro that I found doesn't resemble the description that I gave in this issue, should I close this issue and open a new one?

As far as I can tell, it is not correct (at least for the symptoms I am reporting) that F# Language Services "stop working". In fact, they never start and it is 100% reliable (for me) that if the active document in Visual Studio when it opens is a C# file, F# Language Services never start. I have to switch the active document to a F# file, close Visual Studio, and re-open the (VsVim) solution and then both F# and C# Language services work properly.

[cartermp]

@ricksladkey No need, you can just edit the title and maybe paste this paragraph at the top and then put a separator between that an the original issue text. Thanks for reducing this down.

[cartermp]

@ricksladkey Testing on 15.7.4 with an F# console app and a C# library (.NET Core, .NET Standard), I cannot reproduce what you describe. I'll try it with VsVim.

[cartermp]

Hmmm, on a fresh clone:

1. Open solution
2. Open Interfaces.cs
3. Close solution
4. Re-open solution.
5. Open an F# file (FSharpUtil.fs)

I'm on parallels on the mac right now so it takes ~5-10 seconds, but the language service for F# does light up for me.

[ricksladkey]

@jaredpar Can you repro this?

[ricksladkey]

@cartermp I tried and failed to repro using a minimal two-project solution built from scratch. Then I tried a number of experiments to try to not repro the problem with the full solution, including disabling third-party extensions, reducing the number of open documents, using those two specific .cs and .fs files, etc. but never saw any change in the symptoms.

[cartermp]

I got it to reproduce! 😢

Really strange that this did not reproduce for me on my laptop. But on my desktop, it does.

[cartermp]

cc @TIHan

[jaredpar]

Can you repro this?

I've seen this a few times in the past but I'd never been able to narrow down a repro. I just tried locally and couldn't. But I don't have an RTM build on this machine. Looks like @cartermp has a repro now though.

[cartermp]

Unfortunately, I do not know if this is a regression or not. So this will have to be slated for dev16 instead of the current dev15 trains.

[TIHan]

This should be resolved when we made the Roslyn change to ensure the F# package is loaded.

[cartermp]

Just attempted to reprodue on 15.8.1, and I cannot reproduce this anymore. Which makes sense, since the underlying bug was about not having an F# document open when the solution opens.

@ricksladkey we'll close this out, but if you can reproduce this in 15.8.x again, we can re-open.

[ricksladkey]

@cartermp I open and close Visual Studio a lot and I had systematically avoided leaving the focus on a C# window when I close it. But I thought to revisit this bug and have tried several times and with Visual Studio 15.8.1 and have not been able to repro the problem. I was worried that it was just "accidentally" gone, but it sounds like you have a handle on the root cause and so closing it makes sense.

Thanks because this improves my quality of life!

[cartermp]

Not a problem! Glad this was sorted out.