Improve running/debugging compiler by automatically adding local FSharp.Core and setting --langversion:preview

[abelbraaksma]

Is your feature request related to a problem?

People following the instructions on how to debug or run the compiler through VisualFSharpFull mainly run into three issues:

1. Preview features are not enabled
2. The referenced FSharp.Core.dll is, by default, the 4.7 version
3. FSI inside VS crashes because the key isn't signed

Describe the solution you'd like

For contributors, esp. first-time contributors, it isn't clear that this currently is the way it is, and they may be chasing ghosts, like "why don't I see my recent change" or "why do I get a preview-feature not enabled error"?

Sure, they'll eventually figure it out, or they'll ask on Slack, but it'd be a so much smoother experience if this were to work "out of the box".

Alternatives considered

Anybody currently running into this can use the following instruction, which solves all except the FSI problem (which can run from the commandline to test, even though that's not exactly the same experience). I actually don't know how to solve the FSI problem currently, ideas welcome.

If this cannot be automated, we should add this somewhere prominently in the contributors.md.

Instructions that work "all the time", but that I'd like automated

Thanks to @zanaptak, for testing these instructions and finding gaps in it. It should be good now.

• Checkout this feature branch (feature/string-interp)
• Build by running build.cmd (if you already had a build before switching branches, use git clean -xdf first)
• Open VisualFSharp.sln, select Release and Build All
• Select VisualFSharpFull as startup project, hit Ctrl-F5

A new VS instance is started with the new features selected, but when you create a project, it will, by default, reference an FSharp.Core.dll from NuGet. To fix this:

• Open your test fsproj file and add a line <DisableImplicitFSharpCoreReference>true</DisableImplicitFSharpCoreReference> in the top property group
• In the same property group, add <LangVersion>preview</LangVersion>
• OR In the same property group, add <OtherFlags>--langversion:preview</OtherFlags>
• Add a standard file assembly reference to [fsharp-checkoutdir]\artifacts\bin\VisualFSharpFull\Release\net472\FSharp.Core.dll

A minimal project file for netcoreapp3.1 could look something like this:

  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>netcoreapp3.1</TargetFramework>
    <DisableImplicitFSharpCoreReference>true</DisableImplicitFSharpCoreReference>
    <LangVersion>preview</LangVersion>
    <!-- either the prev. line, or the following line -->
    <OtherFlags>--langversion:preview</OtherFlags>
  </PropertyGroup>

  <PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Debug|AnyCPU'">
	<WarningsAsErrors>3239;25</WarningsAsErrors>
  </PropertyGroup>

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

  <ItemGroup>
    <Reference Include="FSharp.Core">
      <HintPath>D:\Projects\OpenSource\FSharp\artifacts\bin\VisualFSharpFull\Release\net472\FSharp.Core.dll</HintPath>
    </Reference>
  </ItemGroup>
</Project>

[zanaptak]

I needed Build.cmd -c Release to resolve some missing artifact errors in the Visual Studio build.

Then it worked for a simple dummy project, but not a larger project with other project and package references.

I got the larger project to work with the following additional steps:

• In fsharp directory: dotnet pack src\fsharp\FSharp.Core -c Release
• In test project(s):
  • Remove the assembly reference from the fsproj
  • dotnet add package FSharp.Core -v 5.0.0-dev -s "FULL\PATH\TO\fsharp\artifacts\packages\Release\Shipping"

[abelbraaksma]

This may be related: #9845. Though that seems to apply to the public preview editions. The thread here is about using the local builds.

@zanaptak, thanks for the insights. In my experience, it shouldn't be needed anymore to do a build -c release, at least not if you have a clean checkout. When you switch between branches, this can be a solution, though it's often better to do a git clean -xdf.

About dotnet pack: this is a good tip if you want to change the prj files with dotnet commands. The instruction above was meant for direct editing the fsproj file, or using the IDE of VS 2019 to add a reference. Perhaps your approach works good across IDE's and I think in the end the result of that command is at least similar to hand-editing the fsproj.

Note that afaik, you cannot add DisableImplicitFSharpCoreReference implicitly, it needs to be added explicitly. At least in VS I couldn't find a way to do this without adding it manually.