Missing language service features for some projects in a solution if the project is up-to-date

[0x53A]

ref #3054 (comment)

In some projects nothing works at all (colors, completion, ...):

This occurs reliably in a large solution with ~60 projects, but is not reproducible when reduced.

The issue happens in multiple projects, the lowest project is one with 5 dependencies.
If I remove everything except these six projects from the solution, the error stops occurring, even though there should be no change from the view of these projects, so it is impossible for me to provide a reduced reproduction.

For me it looks like something completely unrelated in the solution fucks VS up.

This seems to be related to the up-to-date check:

• If I modify a file and restart VS, stuff works.
• If I build the solution and restart VS, stuff stops working. (Note that before the restart, stuff continues to work even after the build.)

maybe related: #3221

Note: Build always works fine, this is just tooling

[dsyme]

@0x53A I know you've said you can't make a public repro for this, but we'll really need one to make progress on it, unless we get lucky and find the bug by some other means (which is likely sooner or later)

(Also is this using latest nightly? thx)

[0x53A]

Edit: This was a red-herring.

So, I experimented a bit more.

Remember I said above that it works after a clean, and fails after a build?

I was able to reduce it to one dll with one large embedded resource (15MB). Something else in the VS stack seems to choke on that and then poisons something so that VF# fails.

* If I delete the dll and restart VS, everything works.
* If I keep the dll, but remove the embedded resources (using dnspy), then restart VS, everything works.

[dsyme]

@0x53A Interesting, thanks. Can you share that repro?

[0x53A]

No, because when I remove all other projects, the error stops happening.

The error still only happens in the large, 60 project solution.

The solution contains WinForms projects, WPF projects, WIX projects, C++/CLI projects, it must be one of these.

[dsyme]

@0x53A Thanks. Nasty bug, we should protect the Visual F# IDE tools (and Roslyn) from whatever is happening

[0x53A]

Only F# is affected, C# does not have any issues.

[cartermp]

Yikes, that sounds bad. cc @Pilchie this sounds troubling

[dsyme]

@cartermp We really need a standalone repro to make progress on this - if the bug is as described it could come from any of those project flavours

[cartermp]

Agreed. However, in the essence of narrowing the problem down...

@0x53A Is this using VS 2017 Update 2, or Update 3? About when would you say this issue started happening?

[0x53A]

@cartermp VS 2017 Update 2. I have the latest nightly, but have also seen this issue with a colleague, who does not have the nightly.

I'm not sure when it started, at first it was only an unimportant project, so I didn't bother.
That it's now worse is probably related to something changed in our solution (added projects, added references, whatever).

I can try to check old versions from source control, but there are many external references, and some of them are not checked-in, so it may not be trivial to build a version from half a year ago.

[cartermp]

Argh. Sorry to hear that. Maybe there's a way for someone at MS to look at your solution under an NDA or something? I honestly don't know how that process works if it exists. @Pilchie probably would know, though.

[0x53A]

The easiest way (for me :D) would be if you could look at it on my computer through TeamViewer or something like that.

Sending it out may also be possible, but I would probably need to ask my bosses' boss.

It's interesting that we seem to be the only ones hitting this issue, either no-one uses VS2017, or this is really one specific corner case.

[dsyme]

...or this is really one specific corner case.

It feels quite specific. But I do think people often have an option to go back to VS2015 or switch to another editor these days. Which is good...

[0x53A]

But I do think people often have an option to go back to VS2015 ...

Not if you want intellisense for C# / F# vLatest, and C#7 >>> C#6 :\

... or switch to another editor these days ...

Rider works well. =)

---

I will see how hard it is to get rid of the embedded resource, maybe that will "fix" the issue.

[Pilchie]

We could either set up a OneDrive for Business link for you to upload to, or sure, we can try to get someone to remote into the machine.

[0x53A]

It is definitely related to that one project, but it seems like it is not the embedded resource. :-\
I removed all embedded resources from the project, but the issue still occurs. Maybe what "fixed" it when I modified the dll using dnSpy was just the updated timestamp?

Maybe I can find out more tomorrow ...

Edit: Or it is not related to that project, the same happens if I remove any other reference. I just need to cause a reload, then it works.

[0x53A]

So it doesn't seem to be related to anything specific:

• If the project is up-to-date, nothing works.
• If the project is not up-to-date, everything works.
• If I do any change that causes a reload (remove/add reference for example), then colorization kicks in.

So modifying the dll with dnSpy just updated the timestamp, which caused to project to NOT be up-to-date, and "fixed" the issue, but it is not related to the embedded resource.

[dsyme]

If the project is up-to-date, nothing works.

What this says to me is that the underlying problem is something like

• the initial computation of the SourcesAndFlags for the project failed
• the initial computation of the SourcesAndFlags produced a bad set of options which caused something else to fail
• another error occurred which meant Roslyn decided no to list the file for analysis

or something like that. We can definitely fix this if we have a repro (a private ZIP would be enough)

[0x53A]

@dsyme Currently I don't have any spare time to continue with this. Rider works mostly, so I'm using that, and we only have a few F# projects anyway, atm most of my time is in C#.

In a few days I will try again to a) reduce it, and b) send either the original, or the reduced solution to you.

Just to clarify for your title edit, really nothing works, it's not just colorization that's missing. And it's also not time based, if a file got into this state when it was initially loaded, then you can keep it open for hours and colorization (and other features) never appears. The only fix is to force a reload, e.g. by adding/removing a reference.

[forki]

@davkean 15.5.3 has still the same issue.

[forki]

ping.

most annoying issue ever! Complete deal breaker for me to use VS

[dsyme]

@cartermp @KevinRansom @davkean What's the story with this please?

[davkean]

@KevinRansom Didn't you add a workaround for this for F#?

[KevinRansom]

Next thing on my list to look at, but yes I did.

[KevinRansom]

Okay running through these repros:

1. The original repro from @0x53A is based on a desktop F# project file, and so the issue is likely not related.

2. @cartermp 's repro used netsdk, however, it is not repro with 15.6 preview 6.

3. @vasily-kirichenko 's repro is similarly based on a desktop F# file, and includes the community FSharp.Compiler Tools nuget package.

So ...
@davkean this is probably not on you.

Kevin

[KevinRansom]

Okay .... the project file is at fault.

The F# targets are imported twice.

To get it working I:

deleted from the top of the project file.

  <Import Project="..\..\packages\FSharp.Compiler.Tools\build\FSharp.Compiler.Tools.props" Condition="Exists('..\..\packages\FSharp.Compiler.Tools\build\FSharp.Compiler.Tools.props')" Label="Paket" />

Midway through the project file I then replaced this:

<Choose>
    <When Condition="'$(VisualStudioVersion)' == '11.0'">
      <PropertyGroup Condition=" Exists('$(MSBuildExtensionsPath32)\..\Microsoft SDKs\F#\3.0\Framework\v4.0\Microsoft.FSharp.Targets') ">
        <FSharpTargetsPath Condition=" '$(FSharpTargetsPath)' == '' ">$(MSBuildExtensionsPath32)\..\Microsoft SDKs\F#\3.0\Framework\v4.0\Microsoft.FSharp.Targets"</FSharpTargetsPath>
      </PropertyGroup>
    </When>
    <Otherwise>
      <PropertyGroup Condition=" Exists('$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)\FSharp\Microsoft.FSharp.Targets') ">
        <FSharpTargetsPath Condition=" '$(FSharpTargetsPath)' == '' ">$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)\FSharp\Microsoft.FSharp.Targets</FSharpTargetsPath>
      </PropertyGroup>
    </Otherwise>
  </Choose>

with

  <Import Project="..\..\packages\FSharp.Compiler.Tools\build\FSharp.Compiler.Tools.props" Condition="Exists('..\..\packages\FSharp.Compiler.Tools\build\FSharp.Compiler.Tools.props')" Label="Paket" />

Project load looks like:

Probably, the guidance to how to modify project files in order to successfully use the FSharp.Compiler.Tools nuget package should be updated.

Kevin

[KevinRansom]

I propose that we start maintaining this package in this repo, similarly to how we maintain the FSharp.Core nuget package. And perhaps update the template, or add a template that creates a correctly specified project file.

Kevin

[forki]

@KevinRansom I can reproduce the same bug with https://github.com/fsprojects/Paket/blob/master/src/Paket.Core/Paket.Core.fsproj - but that project file looks ok, right?

[forki]

And as described in #3222 (comment) only deletion of obj folder solves it (temporarily)

[0x53A]

@KevinRansom can you please check (with your modified project file):

1. start VS and build project
2. close VS
3. start VS and open project again
4. does it work?

---

Also, the choose block you quoted doesn't import anything, if I follow your instructions, I end up with

  <PropertyGroup>
    <MinimumVisualStudioVersion Condition="'$(MinimumVisualStudioVersion)' == ''">11</MinimumVisualStudioVersion>
  </PropertyGroup>
  <Import Project="..\..\packages\FSharp.Compiler.Tools\build\FSharp.Compiler.Tools.props" Condition="Exists('..\..\packages\FSharp.Compiler.Tools\build\FSharp.Compiler.Tools.props')" Label="Paket" />
  <Import Project="$(FSharpTargetsPath)" />
  <ItemGroup>
    <Compile Include="AssemblyInfo.fs" />
    <None Include="Script.fsx" />
    <Content Include="paket.references" />
  </ItemGroup>

Is that correct?

[KevinRansom]

@0x53A

Hmm Bugger!!! the reload still seems to be an issue

For the repro supplied the project file becomes:

This allows msbuild to set the FSharp build targets to load to :

FSharpTargetsPath = C:\temp\New folder (2)\Repro\packages\FSharp.Compiler.Tools\build\../tools/Microsoft.FSharp.Targets

<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="15.0" DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
  <Import Project="$(MSBuildExtensionsPath)\$(MSBuildToolsVersion)\Microsoft.Common.props" Condition="Exists('$(MSBuildExtensionsPath)\$(MSBuildToolsVersion)\Microsoft.Common.props')" />
  <Import Project="..\..\Other\Build\TimCSDefaultSettings.proj" />
  <Import Project="..\..\Other\Build\TimCSLibDefaultSettings.proj" />
  <PropertyGroup>
    <Configuration Condition=" '$(Configuration)' == '' ">Debug</Configuration>
    <Platform Condition=" '$(Platform)' == '' ">AnyCPU</Platform>
    <SchemaVersion>2.0</SchemaVersion>
    <ProjectGuid>a7cdff79-0ec3-40d1-8281-7aeae67a5678</ProjectGuid>
    <OutputType>Library</OutputType>
    <RootNamespace>DbQueries</RootNamespace>
    <AssemblyName>Precast.DbQueries</AssemblyName>
    <Name>DbQueries</Name>
    <DocumentationFile>$(OutputPath)$(AssemblyName).XML</DocumentationFile>
  </PropertyGroup>
  <PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|AnyCPU' ">
    <DebugSymbols>true</DebugSymbols>
    <DebugType>full</DebugType>
    <Optimize>false</Optimize>
    <Tailcalls>false</Tailcalls>
    <DefineConstants>DEBUG;TRACE</DefineConstants>
    <WarningLevel>3</WarningLevel>
  </PropertyGroup>
  <PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Release|AnyCPU' ">
    <DebugType>pdbonly</DebugType>
    <Optimize>true</Optimize>
    <Tailcalls>true</Tailcalls>
    <DefineConstants>TRACE</DefineConstants>
    <WarningLevel>3</WarningLevel>
  </PropertyGroup>
  <PropertyGroup>
    <MinimumVisualStudioVersion Condition="'$(MinimumVisualStudioVersion)' == ''">11</MinimumVisualStudioVersion>
  </PropertyGroup>
  <Import Project="..\..\packages\FSharp.Compiler.Tools\build\FSharp.Compiler.Tools.props" Condition="Exists('..\..\packages\FSharp.Compiler.Tools\build\FSharp.Compiler.Tools.props')" Label="Paket" />
  <Import Project="$(FSharpTargetsPath)" />
  <ItemGroup>
    <Compile Include="AssemblyInfo.fs" />
    <None Include="Script.fsx" />
    <Content Include="paket.references" />
  </ItemGroup>
  <ItemGroup>
    <Reference Include="mscorlib" />
    <Reference Include="System" />
    <Reference Include="System.Core" />
    <Reference Include="System.Data" />
    <Reference Include="System.Numerics" />
    <Reference Include="System.Transactions" />
    <Reference Include="System.Xml" />
  </ItemGroup>
  <!-- To modify your build process, add your task inside one of the targets below and uncomment it. 
       Other similar extension points exist, see Microsoft.Common.targets.
  <Target Name="BeforeBuild">
  </Target>
  <Target Name="AfterBuild">
  </Target>
  -->
  <Import Project="..\..\.paket\paket.targets" />
  <Choose>
    <When Condition="$(TargetFrameworkIdentifier) == '.NETFramework' And $(TargetFrameworkVersion) == 'v4.6.1'">
      <ItemGroup>
        <Reference Include="FSharp.Core">
          <HintPath>..\..\packages\FSharp.Core\lib\net40\FSharp.Core.dll</HintPath>
          <Private>True</Private>
          <Paket>True</Paket>
        </Reference>
      </ItemGroup>
    </When>
  </Choose>
  <Choose>
    <When Condition="$(TargetFrameworkIdentifier) == '.NETFramework' And $(TargetFrameworkVersion) == 'v4.6.1'" />
  </Choose>
  <Choose>
    <When Condition="$(TargetFrameworkIdentifier) == '.NETFramework' And $(TargetFrameworkVersion) == 'v4.6.1'">
      <ItemGroup>
        <Reference Include="System.ValueTuple">
          <HintPath>..\..\packages\System.ValueTuple\lib\netstandard1.0\System.ValueTuple.dll</HintPath>
          <Private>True</Private>
          <Paket>True</Paket>
        </Reference>
      </ItemGroup>
    </When>
  </Choose>
</Project>

[KevinRansom]

@0x53A This repro uses Tools 4.1.7. That doesn't have the fix. When I copied the latest fsharp compiler and targets to the package directory for the compiler it worked.

I note that someone has published 10.0.1 as a nugget package. That set of tools should have the correct fix. Would you like to try with a more recent compiler?

[KevinRansom]

@0x53A what I mean is, try the project when using the 10.0.1 nuget package for F#.

https://www.nuget.org/packages/FSharp.Compiler.Tools/

It has a targets file with the fix:

https://github.com/Microsoft/visualfsharp/blob/dev15.6/src/fsharp/FSharp.Build/Microsoft.FSharp.Targets#L359

[dsyme]

Just to say that I remember seeing this bug with bin/obj folders. I'm pretty certain it was anything to do with FCT though since I recall it in much smaller projects that didn't use FCT. @forki also said in private DM that he thought it was nothing to do with FCT - it was happening all the time for him - and he stopped using VS on those projects as a result.

But that's just all anecdotal. We need a repro. I haven't been doing these kind of projects in VS for a while though either.

[cartermp]

The reliable repro on this issue involves FCT, so it sounds like the issue is resolved as far as that is concerned.

@forki's issues and what you have seen are likely orthagonal issues with /bin and /obj as it relates to the new project system's up to date checker. @KevinRansom has since submitted a fix for that, but it's likely that issues unrelated to FCT lie there and not here.

[0x53A]

I can still reproduce it with FCT 10.0.1.

But there was one change, now VS crashes hard ;D

---

Edit:

1. Update VS to latest preview
   

2. Create a new F# old-sdk project
   

3. Install the latest FCT nuget
   

4. Build project

5. Close VS

6. Reopen VS and reload project
   

For completeness sake, I have uploaded the project (https://github.com/0x53A/FCT_Test), but I hope you can reproduce it with these few steps as well.

Manually modifying the project file didn't change anything, @KevinRansom, did I do it correctly? Please see commit 0x53A/FCT_Test@7823e86

---

(the hard crash wasn't reproducible)

[forki]

I still see the isue in 15.6.3 - sigh

[0x53A]

@forki, quoting @KevinRansom :

It won't make it into 15.6, but should first appear in a 15.7 preview when they come on stream.

[forki]

Just saw it again with 15.7.4 on paket solution

[davkean]

Steffen, you know better than to comment on old bugs. File a new bug with either clear repro steps or at least a snapshot of the project folder in the broken state.

[forki]

It's same repro as always. But sure I can open yet another issue later this week. David Kean <[email protected]> schrieb am Do., 21. Juni 2018, 11:09:

…

Steffen, you know better than to comment on old bugs. File a new bug with either clear repro steps or at least a snapshot of the project folder in the broken state. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#3222 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AADgNCD9l5BZPLw_De29xFTCPsqBDiP5ks5t-2K9gaJpZM4N-pdy> .