Building existing .fsproj with xplat MSBuild

[ncave]

If I create a new FSharp .fsproj project using the VS2015 F# console project template,
should I be able to build it using the latest xplat MSBuild 14.1 configured like this?
The build fails because paths are incorrect, but even after overwriting the properties with correct paths to F# targets, still getting this:

d:\Projects\ftest\ftest.fsproj" (default target) (1) ->
(CoreCompile target) ->
  C:\Program Files (x86)\Microsoft SDKs\F#\4.0\Framework\v4.0\Microsoft.FSharp.Targets(155,9): error MSB4062: The "Fsc" task could not be loaded from the assembly C:\Program Files (x86)\Microsoft SDKs\F#\4.0\Framework\v4.0\FSharp.Build.dll. Could not load file or assembly 'FSharp.Core, Version=4.4.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The system cannot find the file specified. Confirm that the <UsingTask> declaration is correct, that the assembly and all its dependencies are available, and that the task contains a public class that implements Microsoft.Build.Framework.ITask. [d:\Projects\ftest\ftest.fsproj]

How can I add this missing dependency to the build task?

The same project builds just fine with MSBuild 14.0 on the same machine, so all the required dependencies are there.

[rainersigwald]

Does that FSharp.Build.dll target .NET Core (or netstandard)? Based on the linked F# issue, I would expect the compiler to come in through a NuGet package, rather than be installed in Program Files.

Maybe I'm unclear on the scenario, though--can you describe it in more detail?

[ncave]

@rainersigwald FSharp.Build.dll is part of the standard Visual F# 4.0 compiler coming with VS 2015 (so not .NET Core). The scenario I was interested in was more of a general question about the direction that xplat MSBuild is going:

"Should we expect the latest xplat MSBuild 14.1 configured like this to be able to compile existing projects that use non-netcore compilers in the build steps? Or do the projects first needs to go through some transformation to use different targets and compiler versions?"

My apologies if the question does not make much sense.

[dsyme]

@ncave Perhaps add the "Repro", "Expected", "Actual" description for the issue? With step-by-step repro? Just so we can clarify the expectation and what you're actually seeing in a reproducible step-by-step way

[KevinRansom]

@ncave
Hi, the currently shipped fsharp project templates will need to be reworked in order to work with the latest crossplat msbuild. We haven't yet done that work or designed it even. It is something we will get to before Dev 15 ships, But right now our entire focus is on getting the cross platform compiler working well, and on the Roslyn IDE integration for F# and the necessary making sure that XCopy deployment of Visual Studio with F# works great.

I f you are interested, it would be great if you could look at what might be needed and make a proposal, or even a PR. I know that the F# community would help out.

Thanks for the report,

Kevin

[dsyme]

@KevinRansom Hmmm... For x-plat... Mono XBuild can build existing F# projects just fine.

I don't understand why existing projects on Windows wouldn't build just fine with the opensource MSBuild. What's it doing that's not compatible? And what's the point of Microsoft open-sourcing and releasing an non-backwards compatible version of MSBuild? That would seem worse than doing nothing at all, it would needlessly split F# and C# projects between "old" projects (which work with existing tooling) and "new" ones (which only work with new tooling).

Perhaps I'm just not understanding this penchant for breaking compat. I thought the open source MSBuild would surely be compatible and able to act as a replacement for the existing MSBuild on Windows.

[rainersigwald]

This is definitely confusing today and we haven't totally figured out the future yet. I filed some issues to capture what we're thinking about for this.

@ncave @dsyme Existing projects on Windows will be able to build with MSBuild 15, but they may require that you build with MSBuild hosted on the desktop CLR. That's because some of the mechanisms used to target the full framework are pretty entangled with CLR features that don't exist in .NET Core, like the GAC. See #713 for details.

Mono is an interesting case to compare, because it implements concepts (like the GAC) that were deliberately left out of .NET Core. MSBuild/Mono should be able to build existing projects, just like MSBuild/desktop. And it should be able to do so even on other OSes. But MSBuild/netcore won't be able to resolve from the (nonexistent) GAC on macOS.

On Windows, there's a possibility that we could push the full-framework-dependent work into a full-framework executable (#711). But I'm not sure that solves everything.

As @KevinRansom mentioned, part of making F# fit fully into the new xplat/.NET Core world will be (re)designing targets so that they don't depend on things that don't make sense in .NET Core. The new targets should be able to produce assemblies that work on both .NET Core and the full desktop framework, but they may have to be constructed slightly differently (for instance, referring to packages when you want platform assemblies, instead of names that get resolved from the GAC). This is ongoing for C# as well, and we can learn from decisions made for that.

[ncave]

Thank you @rainersigwald and @KevinRansom for the thorough explanation.

[dsyme]

@rainersigwald Yes, thanks for the explanation. I hadn't realized how entangled this was with the fact you're using .NET Core 1.0 to execute the OSS MSBuild. I guess I expected the behaviour of MSBuild to be independent of the machinery being used to execute the tool - though of course the fact that you can load addin tasks into the tool is a big issue too.

(Note, we have some similar issues with the F# compiler and F# Interactive scripting tools too - so we know it's not easy)

[enricosada]

@dsyme an example of improve msbuild target (using a new target compatibile with old, but .net core ready), c# is cleaning up in dotnet/project-system#40

[Sarabeth-Jaffe-Microsoft]

Closing this issue. Please reference #711 and #713.