FSharp.Compiler.Tools.4.1.0 does not work with net46 fsproj in VisualStudio

[0x53A]

I want to use the F#4.1 compiler with VS2015.

Repro steps

Create a new F# console project in Visual Studio 2015.

Add the package FSharp.Compiler.Tools.4.1.0.

Run build.

Expected behavior

It should compile the project using the new compiler.

Actual behavior

1>------ Rebuild All started: Project: FsTest, Configuration: Debug Any CPU ------
1>	c:\users\lr\documents\visual studio 2015\Projects\FsTest\packages\FSharp.Compiler.Tools.4.1.0\build\netcoreapp1.0\fsc.dll -o:obj\Debug\FsTest.exe -g --debug:full --noframework --define:DEBUG --define:TRACE --doc:bin\Debug\FsTest.XML --optimize- --tailcalls- --platform:anycpu32bitpreferred -r:"C:\Program Files (x86)\Reference Assemblies\Microsoft\FSharp\.NETFramework\v4.0\4.4.0.0\FSharp.Core.dll" -r:"C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.6.1\mscorlib.dll" -r:"C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.6.1\System.ComponentModel.Composition.dll" -r:"C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.6.1\System.Core.dll" -r:"C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.6.1\System.dll" -r:"C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.6.1\System.Numerics.dll" --target:exe --warn:3 --warnaserror:76 --vserrors --LCID:1033 --utf8output --fullpaths --flaterrors --subsystemversion:6.00 --highentropyva+ --sqmsessionguid:f4681a33-2fc3-45ca-93a7-c1cdcf856afe "C:\Users\lr\AppData\Local\Temp\.NETFramework,Version=v4.6.1.AssemblyAttributes.fs" AssemblyInfo.fs Program.fs 
1>C:\Program Files (x86)\Microsoft SDKs\F#\4.0\Framework\v4.0\Microsoft.FSharp.Targets(155,9): error MSB6006: "fsc.dll" exited with code -532462766.
1>Done building project "FsTest.fsproj" -- FAILED.
1>
1>Build FAILED.
========== Rebuild All: 0 succeeded, 1 failed, 0 skipped ==========

notice how it runs fsc.dll

Workaround

I edited packages\FSharp.Compiler.Tools.4.1.0\build\FSharp.Compiler.Tools.props to look like this:

<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003">

  <PropertyGroup>

    <!-- Default to netcoreapp fsc -->
    <FscTaskAssemblyPath>$(MSBuildThisFileDirectory)../tools/FSharp.Build.dll</FscTaskAssemblyPath>
    <FscToolPath>$(MSBuildThisFileDirectory)../tools</FscToolPath>
    <FscToolExe>fsc.exe</FscToolExe>
    <FscToolFullPath>$(MSBuildThisFileDirectory)../tools/fsc.exe</FscToolFullPath>
    
  </PropertyGroup>

</Project>

Now it correctly calls the compiler, and a simple program compiles correctly:

Notice how the build succeeds, even though intellisense complains about struct because it is Visual Studio 2015.

[dsyme]

@0x53A Please submit that as a PR? (Also if you find a way to NGEN the fsc.exe prior to execution that would be awesome - assuming admin privileges are available)

[0x53A]

@dsyme Are you familiar with the package? To be honest, I'm not even sure if my scenario is supposed to work, after looking a bit into it I think this package is primarily meant for net core support?

The tool to run (exe for netfx / dll for netcore) would need to be switched based on some variable, I think I could use $(TargetFrameworkIdentifier) =='.NETCoreApp'. (ref https://github.com/dotnet/corefx/blob/master/Documentation/project-docs/target-dotnetcore-with-msbuild.md)

Roslyn has two packages:
https://www.nuget.org/packages/Microsoft.Net.Compilers/ and https://www.nuget.org/packages/Microsoft.Net.Compilers.netcore/

So maybe the correct solution would be to publish a second package with my changes, FSharp.Compiler.Tools.FullFx (or similar)?

Regarding ngen: I don't think this decision should be taken by the package. If the user want's ngen, they should restore the package and then manually run ngen in the build script.
What roslyn uses is a (optionally enabled by $(UseSharedCompilation)) compiler server, so that the jit cost is only paid once.

@enricosada Do you think I should try to modify this package, or create a second one? My goal is to use something equivalent to Microsoft.Net.Compilers for full framework in Visual Studio.

[dsyme]

@dsyme Are you familiar with the package? To be honest, I'm not even sure if my scenario is supposed to work, after looking a bit into it I think this package is primarily meant for net core support?

The primary intention of the package is .NET Framework support. .NET Core support was just added recently. However we have never checked out whether "add package" would wire up the compiler - we just wired up the properties by hand whenever the compiler was actually being used

@enricosada Is the .props file part of the .NET Core support? What do you think the right thing to be doing here is?

[dsyme]

@0x53A Note that this package is actually defined in http://github.com/fsharp/fsharp

[enricosada]

It should compile the project using the new compiler.

atm is not supported to work like that, just because is not implemented as use case.
old way (and supported), is to use FscToolPath property to point to local installation.

That said, FSharp.Compiler.Tools package can do that, if correctly authored.
NGen can be added probably, but as first run, not at install time (there is no way to do that afaik). but is fragile.
No need to have two packages, roslyn do that because of split needed to embeed in VS and dotnet/cli.
Also we are going to add netcoreapp1.1 fsc there too soon (so net45, netcoreapp1.0, netcoreapp1.1 and future netcoreapp2.0)

anyway ihmo should closed and moved in fsharp/fsharp repo. I'll comment your pr too.