@enricosada I think replacing the "build coreclr" path (rather than adding a new one) would be better - why would we keep the old one active in master?

No reason at all, is just another pr (i can do that) because i fear big one shot changes.
I can replace build coreclr completly adding new fsproj in parallel, and use .net core to build it. That remove all complexity for coreclr from fsproj/build script (see below).
Build artifacts (fsc.dll, fsharp.core.dll, etc) can be placed in expected directories, so rest of build.cmd doesnt change.
that was my idea, just splitted in two PR (this is the first one)

@enricosada I suspect very few of the people have actually use Preview 4 and the new .csproj/msbuild-based .NET Core SDK. I had zero real context on all of this until I read this PR.

The csproj VS tooling is out of preview in VS2017 RC3. the sdk itself is really near rtm.
I'll probably use that at work too when VS2017 goes RTM, to replace our current aspnetcore with project.json and VS2015 btw (and we use it with .NET FW/iis, not .net core).

For c# guys is better, and they are gonna use that, because msbuild format is easier than project.json (less alien). Also VS2017 already support it, so is not difficult to sell at all.

@enricosada Could you publish a prelim version of Microsoft.FSharp.Compiler.Sdk.netcore yourself? Or is the signing issue to problematic?

I can do that, that's what the build script does btw. I just need to change the name, but is not a problem. can be put inside FSharp.Compiler.Tools too (so it support netcore and net40).
I can generate the package with script, and overwrite the assemblies with the signed one generated by build coreclr . result is here in dev feed, i already use that to boostrap things (because easier).

Working example using dev feed are inside this PR

cd examples\dotnetcoresdk\simple\console
dotnet restore
dotnet run

@enricosada The duplication of build/install scripts is pretty disturbing.
Perhaps listing all the stuff that will eventually be deleted would be helpful.

There are two parts, build script orchestration and project files. Fsc.fsproj is a proj, but build require nuget restore/packaging/signing/runtests. That can be offloaded to .net core sdk. Some deletion will
greatly simplify files, but not remove it completly

I cannot migrate project files until VS support new fsproj, but we can simplify greatly current script. It's ortogonal to my pr (needed to improve sdk), can be done anyway (just give me a go).

I assume i will build the .net core version of components with new fsproj and sdk, so we remove current complexities in old fsproj.
I assume build orchestration goes in a msbuild .proj, using the sdk featuers (like my pr)
I assume all stuff like restore/packaging/runtests will be executed by .net core sdk

To delete:

• msbuild location code -> dotnet msbuild
• .nuget directory => dotnet nuget
• Tools directory (minus specific stuff like localitazion target) because is pratically a custom packaged version of the sdk. And not used because new fsproj build netcore. Signing is already support by sdk.
• init-tools and install script, useless, because are a custom version of the official .net core install script (same features)
• all project.json
• all netcore related stuff
• tests runner from build script complexity => dotnet run or dotnet test

it's possibile to dotnet build the old fsproj (will use normal targets), just use the new msbuild.exe. That remove lot of complexity in build script. and make easier to run xplat

Old fsproj in parallel to new fsproj. used for .net core. Common properties like defines can be shared using specific .props file (like my pr)
Having both side by side, the new fsproj can also include build of net40 too, so when vs support it, we can just remove the old one.

Note, the .NET Core SDK can build ALL framework, so .NET Framework, .NET Core, Portalble profiles, etc in same fsproj. is not only for netcore.
And dotnet build -> dotnet msbuild /t:Build, no magic

• where is msbuild? dotnet msbuild
• where is nuget? dotnet nuget
• restore all needed packages? dotnet restore --packages /path/to/save/packages (aftet that the fsproj know that path, no need to manually fix reference)
• build fsc as net40? dotnet build src\fsharp\fsc\fsc.fsproj -f net40 -c Release
• generate the fsharp core package? dotnet pack src\fsharp\fsharp.core\fsharp.core.fsprj -c Release /p:Version=4.1.1.0 (the package metadata are property inside fsproj, or extenal props file, or from cmdargs)

like before, it's msbuild so following works:

• build fsc as using proto? dotnet build src\fsharp\fsc\fsc.fsproj -f netcoreapp1.0 -c Release /p:FscPath=protodir/fsc.exe
• run cambride test? dotnet run tests\fsharp\FSharp.Tests.FSharpSuite.fsproj (or dotnet test for nunit like experience, with logs/filter/etc). Will continue to work from fsi obv.

The same build workflow can be used by developers too

• cd src/fsharp/Fsc
• dotnet restore
• dotnet run -f net40 //build all deps, run fsc for net40
• dotnet publish -f netcoreapp1.0 //build all deps, save in a dir an xcopy deployable fsc for .netcore
• dotnet publish -f net40 //build all deps, save in a dir an xcopy deployable fsc for .net 40

about other required stuff, like signing and vsix creation, can be done like dotnet/cli repository.