Downgrade build script for MSBuild 12.0.

[Rodhern]

Major caveat: I don't actually know what I am doing.

Instead of creating my comment as an issue I have made it a pull request.

When I try to run the build (build.bat) with MSBuild 12.0 the build tools complain that there are missing xmlns attributes on the .target Project tags, and that they do not understand the new(?) inlined CopyToOutputDirectory attributes for the None tags in the .fsproj files.

Can this be fixed, or will it just ruin other scenarios instead?

[dsyme]

@Rodhern Why are you using such an old MSBuild?

[Rodhern]

Hi @dsyme.

I will give the long answer to what I am doing. Feel free to skip or glance over my answer if that was not how your question was meant.

My main example is plugin programming for a computer game named Kerbal Space Program. Plugins are written for Unity (a product designed for .Net-like scripting via Mono) and need to target the equivalent of .NET 3.5 (a .NET Standard 2.0 compatible version of Unity has since been announced, and may or may not be retrofitted to existing games).

Most players/developers write their game plugins in C#. I favour F# and I think it is quite cool that we are able to write our cross platform game plugins in F#. However, the average player/developer probably does not usually dabble in F# and therefore needs access to an appropriate FSharp.Core.dll to get going in earnest. In an attempt to make it a bit easier to find I have uploaded a Nuget package with an Apache 2.0 licensed FSharp.Core.dll targeting .NET 3.5 (and thus suitable for Unity).

I then thought I would check if I could compile a newer FSharp.Core.dll targeting .NET 3.5 with its new MIT license. I happened to have MSBuild 12.0 (Visual Studio 2013) on my computer already and I found in build.bat that the build seems to explicitly support MSBuild 12.0. I then ran the default (net40 targeted) build and found out that I needed to resolve the two mentioned issues (xmlns attribute and CopyToOutputDirectory attribute) to have MSBuild 12.0 succeed.

So no good reason for using MSBuild 12.0 really, just happened to work out that way.

[dsyme]

@Rodhern Thanks for the explanation!