Fsharp: Builds against target framework net35/net40 fail with the VS16.5 update -- Cannot read or write file Fsharp.Core.dll

[SteveGilham]

Builds of F# projects against target framework net35 fail with the VS16.5 update. This happens with both old-style long-form projects or the new lightweight ones.

Repro steps

The simplest repro is

1) dotnet new classlib -lang F#
2) edit project as follows to target .Net Framework 3.5

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <TargetFramework>net35</TargetFramework>
  </PropertyGroup>

  <ItemGroup>
    <Compile Include="Library.fs" />
  </ItemGroup>

  <ItemGroup>
    <PackageReference Update="FSharp.Core" Version="3.0.2" />
  </ItemGroup>

</Project>

3) dotnet restore
4) msbuild [project]

Expected behavior

Trivial compilation just works

Actual behavior

"C:\Users\steve\Documents\scratch\scratch.fsproj" (default target) (1) ->
(CoreCompile target) ->
  FSC : error FS0229: Error opening binary file 'C:\Users\steve\.nuget\packages\fsharp.core\3.0.2\lib\net35\FSharp.Core .dll': Cannot read or write file [C:\Users\steve\Documents\sscratch\scratch.fsproj]
  FSC : error FS3160: Problem reading assembly 'C:\Users\steve\.nuget\packages\fsharp.core\3.0.2\lib\net35\FSharp.Core. dll': The exception has been reported. This internal exception should now be caught at an error recovery point on the stack. Original message: Error opening binary file 'C:\Users\steve\.nuget\packages\fsharp.core\3.0.2\lib\net35\FSharp.Co re.dll': Cannot read or write file) [C:\Users\steve\Documents\scratch\scratch.fsproj]
  error FS0073 : internal error : BuildFrameworkTcImports: no successful import of C:\Users\steve\.nuget\packages\fshar p.core\3.0.2\lib\net35\FSharp.Core.dll [C:\Users\steve\Documents\scratch\scratch.fsproj]

Known workarounds

Using an older compiler version

Related information

Windows 10 Home build 1909
Visual Studio 16.5

[SteveGilham]

Also failing in similar style
net35 and fsharp.core 4.1.18
net40 and 4.1.18
and net4x and 3.0.2

[SteveGilham]

Using Microsoft.NETFramework.ReferenceAssemblies.net20, the issue can be reproduced in a pure dotnet build context

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <TargetFramework>net20</TargetFramework>
  </PropertyGroup>

  <ItemGroup>
    <Compile Include="Library.fs" />
  </ItemGroup>

  <ItemGroup>
    <PackageReference Include="Microsoft.NETFramework.ReferenceAssemblies.net20" Version="1.0.0">
      <PrivateAssets>all</PrivateAssets>
      <IncludeAssets>runtime; build; native; contentfiles; analyzers; buildtransitive</IncludeAssets>
    </PackageReference>
  </ItemGroup>

  <ItemGroup>
    <PackageReference Update="FSharp.Core" Version="4.1.18" />
  </ItemGroup>

</Project>

[TIHan]

Thank you for reporting this. This looks to be a regression and will make this the highest priority.

[inosik]

Same with FSharp.Core 4.0.0.1.

[macdonald-keith-vmware]

and same with FSharp.Core.4.0.0.0
but I'm sure you knew that... :)

[cartermp]

Just to update folks on this - the fix is already deployed in master and will be released in the VS 16.6 release. We're currently going through the process of getting a backport of that fix into a servicing release of 16.5. If any folks here who were affects (@SteveGilham @inosik @macdonald-keith-vmware) have time to verify if it works/fails on the 16.6 preview, that would be appreciated.

Just to set expectations, servicing a release carries a high bar. The more servicing fixes we take, the higher the risk of accidentally breaking something else in an otherwise stable release. We're currently going through the approval process and we'll report back on the outcome of that.

[SteveGilham]

I've installed VS2019 16.6 preview 1.0 and reset my work to the point where I spotted the issue.

• v16.5 -- fails as reported
• v16.6 preview 1.0 -- SUCCESS

[Tener]

Is there a workaround that can be applied to make it work with v16.5 so that one can avoid having to install v16.6 preview 1.0?

[SteveGilham]

@Tener My current work-around is to get an older compiler and use that. To be precise, I've added used a simple project to get the FSharp.Compiler.Tools package locally

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <TargetFramework>net47</TargetFramework>
  </PropertyGroup>

  <ItemGroup>
    <None Remove="*.*" />
  </ItemGroup>

  <ItemGroup>
    <PackageReference Include="FSharp.Compiler.Tools" version="10.2.3" />
  </ItemGroup>
</Project>

call it fsc.csproj, then get that package locally

dotnet restore --packages .\packages fsc.csproj

and put a conditional override of the compiler to any project with the affected target framework, like

   <FscToolPath Condition="'$(TargetFramework)' == 'net35'">$(ProjectDir)..\packages\fsharp.compiler.tools\10.2.3\tools</FscToolPath>

[cartermp]

Thanks for confirming that the preview does work for you, @SteveGilham.

Update: The fix for this issue has been approved for the 16.5.2 servicing release, which should be made available sometime next week. Sorry for disruptions to usual workflow here.

[Tener]

Thanks @SteveGilham, looks very simple. VS2019 crashes a lot less for me than VS2017 so this is really valuable thing.
@cartermp really good news about the service release.

[cartermp]

@Tener sorry to hear about crashes. Would you mind filing an issue so we can look into it? We've been addressing various VS perf problems for a while now, but we'd love to see what we can do to help more. We've got some more coming down the pipeline, too, but only a few test cases we've been using to test it out with.

Also happy to chat over email (phcart at microsoft dot com) if it involves more sensitive info about the codebase. I'm subject to an NDA when communicating over email. We've done a few engagements with folks before including looking directly at build logs and helping with suggestions that can make their lives a lot better while fixes are being developed.

[Tener]

@cartermp I was thinking about filing an issue but first wanted to check how things are with the latest fixes. Happy to share more details over email, I'll reach out soon. I was able to apply workaround from @SteveGilham - the projects now compile - but it looks like Intellisense is still disabled (no type information, go to definition does not work etc.). I assumed this was caused by the same underlying problem but now I'm not completely sure. I'll see if I can install the preview to test this.

[cartermp]

@Tener thanks for reaching out over mail. re: the workaround - this does allow for compilation, but that package does indeed disable intellisense since it's not using the actual compiler/language service that VS ships with. So it's a quick workaround in the short term but not something to use beyond unblocking compilation.

[cartermp]

Sorry for an additional delay here, folks. The chain of insertions has made this risky to get in for the 16.5.2 patch:

• F# compiler and tools --> VS
• F# coreclr compiler --> .NET SDK --> new SDK servicing release --> VS

The latter is too risky to do for the 16.5.2 release since the SDK patch for 16.5.2 has already been inserted and can't rev yet. So we're bouncing this out to the 16.5.3 patch which will be April 7th or so. Until then, VS preview does have the fix and should be stable enough for regular use.

[Happypig375]

March 7th is nearly one year later though

[cartermp]

thanks

[SteveGilham]

Confirming that SDK 3.1.201 and VS 16.5.3 are good.

[cartermp]

Thanks @SteveGilham

[inosik]

Still getting this error with SDK 3.1.201 when trying to build Hedgehog.

[cartermp]

@inosik It'll be in the next rev of the SDK. The last build available that isn't a preview is from March 24th.

[inosik]

OK, I thought 3.1.201 was already patched.

[0x53A]

Do you have a timeline for the next SDK 3.1.x release?

[cartermp]

Nope, no timeline. It should be aligned with the VS 16.6 release though

[inosik]

SDK 3.1.202 seems to be fixed.