Use new fsproj, replace project.json

[enricosada]

Replace current project.json based .net core sdk with new fsproj.

Migraton guide: https://github.com/dotnet/netcorecli-fsc/wiki/How-to-migrate-preview2-projects-to-rc4

PRO:

• aligned with new sdk rc4 and rtm
• more alike of old fsproj, easier diff
• can share props files (defines?) with old fsproj
• can be in same directory of old fsproj, the fsproj name doesnt matter (set AssemblyName prop)
• can build BOTH net451 and netstandard, optionally, if we want do that.

Example lib: https://github.com/dotnet/netcorecli-fsc/blob/master/examples/rc4/lib/lib.fsproj

/cc @dsyme @gentauro

[ghost]

Hi @enricosada.

Just a few things. I'm interested in using the F# Compiler Service in a similar manner to how it's used in:

• https://github.com/Microsoft/visualfsharp/blob/2656357e014dc96a8b295f9df1d5d016cec8351c/src/fsharp/Optimizer.fs

open Microsoft.FSharp.Compiler.AbstractIL
open Microsoft.FSharp.Compiler.AbstractIL.Diagnostics
open Microsoft.FSharp.Compiler.AbstractIL.IL
open Microsoft.FSharp.Compiler.AbstractIL.Internal
open Microsoft.FSharp.Compiler.AbstractIL.Internal.Library
open Microsoft.FSharp.Compiler.AbstractIL.Extensions.ILX

open Microsoft.FSharp.Compiler
open Microsoft.FSharp.Compiler.Lib
open Microsoft.FSharp.Compiler.Range
open Microsoft.FSharp.Compiler.Ast
open Microsoft.FSharp.Compiler.ErrorLogger
open Microsoft.FSharp.Compiler.Infos
open Microsoft.FSharp.Compiler.PrettyNaming 
open Microsoft.FSharp.Compiler.Tast 
open Microsoft.FSharp.Compiler.TastPickle
open Microsoft.FSharp.Compiler.Tastops
open Microsoft.FSharp.Compiler.Tastops.DebugPrint
open Microsoft.FSharp.Compiler.TypeChecker
open Microsoft.FSharp.Compiler.TcGlobals
open Microsoft.FSharp.Compiler.Layout
open Microsoft.FSharp.Compiler.TypeRelations

To keep it to a basic level I was aiming to create an F# script where I would just #I and #r the FCS. I managed to do that:

but as you can see in the picture there are many modules/libraries that are present in the FCS nuget package.

Note: Since I have updated dotnet from preview2 to rc4 I no longer have /usr/share/dotnet/bin/ nor System.Reflection.Metadata.dll so I can't use the nuget package of FCS anymore ...

Btw I tried to upgrade to latest rc (dotnet --version 1.0.0-rc4-004771) and did the following:

dotnet new classlib -lang F# && dotnet build

giving me the following errors:

Microsoft (R) Build Engine version 15.1.545.13942
Copyright (C) Microsoft Corporation. All rights reserved.

/usr/share/dotnet/sdk/1.0.0-rc4-004771/Microsoft.Common.CurrentVersion.targets(2620,7): error MSB4057: The target "CreateManifestResourceNames" does not exist in the project. [/home/mon/tmp/fcs/lib/lib.fsproj]

Build FAILED.

/usr/share/dotnet/sdk/1.0.0-rc4-004771/Microsoft.Common.CurrentVersion.targets(2620,7): error MSB4057: The target "CreateManifestResourceNames" does not exist in the project. [/home/mon/tmp/fcs/lib/lib.fsproj]
    0 Warning(s)
    1 Error(s)

Time Elapsed 00:00:00.36

I tried the .fsproj file you created but that gives me the following error:

Microsoft (R) Build Engine version 15.1.545.13942
Copyright (C) Microsoft Corporation. All rights reserved.

/usr/share/dotnet/sdk/1.0.0-rc4-004771/Sdks/Microsoft.NET.Sdk/build/Microsoft.NET.Sdk.DefaultItems.targets(165,5): error : Duplicate 'Compile' items were included. The .NET SDK includes 'Compile' items from your project directory by default. You can either remove these items from your project file, or set the 'EnableDefaultCompileItems' property to 'false' if you want to explicitly include them in your project file. For more information, see https://aka.ms/sdkimplicititems. The duplicate items were: 'Library.fs' [/home/mon/tmp/fcs/lib/lib.fsproj]

Build FAILED.

/usr/share/dotnet/sdk/1.0.0-rc4-004771/Sdks/Microsoft.NET.Sdk/build/Microsoft.NET.Sdk.DefaultItems.targets(165,5): error : Duplicate 'Compile' items were included. The .NET SDK includes 'Compile' items from your project directory by default. You can either remove these items from your project file, or set the 'EnableDefaultCompileItems' property to 'false' if you want to explicitly include them in your project file. For more information, see https://aka.ms/sdkimplicititems. The duplicate items were: 'Library.fs' [/home/mon/tmp/fcs/lib/lib.fsproj]
    0 Warning(s)
    1 Error(s)

Time Elapsed 00:00:00.24

This is not a matter of life-and-death so if you have any other things that are a priority, please spend your time on those.

[ncave]

@enricosada Great guide, thanks!
I'm having issues adding multiple embedded resources (more than one), have you seen anything mentioned about that?

[enricosada]

@gentauro you need to do dotnet restore before dotnet build, just once or if you change packageref. it's the same for c#, it's used to restore all reference from nuget.

dotnet new lib -lang F# && dotnet restore && dotnet build - v n

• lib=classlib template, but class 👎 with F# (and shorter).
• the -v n add verbose build log, so you can see fsc arguments, because i think you'd like to see these 😄

[enricosada]

@ncave you mean <EmbeddedResource? can you open an issue on https://github.com/dotnet/netcorecli-fsc/issues about that? with a mini repro, if possibile, so i can add to test suite too 😄
Btw adding scenario to test suite is really easy. see an example test it just invoke dotnet commands, and copy from test/testAssets directory

with new sdk, by default (it's the same for c#), there is a wildcard include, like <EmbeddedResource Include="**/*.resx" />. defined in $sdkInstallDir/sdk/1.0.0-rc4-004771/Sdks/Microsoft.NET.Sdk/build/Microsoft.NET.Sdk.DefaultItems.props

  <ItemGroup Condition=" '$(EnableDefaultItems)' == 'true' ">
    <Compile Include="**/*$(DefaultLanguageSourceExtension)" Exclude="$(DefaultItemExcludes);$(DefaultExcludesInProjectFolder)" Condition=" '$(EnableDefaultCompileItems)' == 'true' " />
    <EmbeddedResource Include="**/*.resx" Exclude="$(DefaultItemExcludes);$(DefaultExcludesInProjectFolder)" Condition=" '$(EnableDefaultEmbeddedResourceItems)' == 'true' " />
  </ItemGroup>

If you define <EmbeddedResource in fsproj you will get duplicated items error.
You can opt out the wildcard include adding property EnableDefaultEmbeddedResourceItems to false

[ncave]

@enricosada I know, I tried either way, but I'm getting this error if I have more than one .resx in the project:

C:\Program Files\dotnet\sdk\1.0.0-rc4-004771\Microsoft.Common.CurrentVersion.targets(2857,5): error MSB3577: Two output file names resolved to the same output path: "obj\Release\netstandard1.6\.resources

[enricosada]

@ncave sry, that was something that was changed in rc3, so i had to say it because it's a common error with the implicit default wildcard includes.

Seems something is not implemented yet (empty filename). Just open an issue, i'll fix that :D it' easy now, i'll just publish FSharp.NET.Sdk 1.0.1.
Also reading code probably i not implemented it in target file, my bad, but should be ok copying the old fsharp target, using the task from FSharp.Build like FscTask does. Or better check if we can reuse c# task/target directly, instead of reimplement it.

[ghost]

you need to do dotnet restore before dotnet build

That did the trick, thanks 👍

[enricosada]

@ncave the resx issue is fixed with the new published FSharp.NET.Sdk v1.0.1 package

[dsyme]

@enricosada Re my comment on other thread - I'd really appreciate help to see this addressed #705 (comment)

[enricosada]

adding more people i know who can help with this issue ( @forki @cloudRoutine @adamchester @neoeinstein ), i can review/hints.

@dsyme but if noone step up, i'll do that friday.

I'll reply your points on the other issue

Currently this project requires the old preview2-1-003177 version of the .NET Core tooling to even build build.cmd All.NetCore. (If you have a later version installed then the command dotnet restore -v Information fails while running build.cmd All.NetCore). This is wrong since most people now have a later version of the tooling installed.

project json -> fsproj.

The AppVeyory CI. This is a major problem but maybe there's a way to tell AppVeyor to acquire the latest version of the tooling?

Install is just download a zip, unzip, add to path. Or download install script and run it.

with ref of docs official docs https://docs.microsoft.com/en-us/dotnet/articles/core/tools/using-ci-with-cli.

i updated the appveyor.yml and travis in this PR dotnet/docs#1556 not yet merged, so use that 😄

Nor do I understand how we are expected to check for the right version and acquire it if necessary.

use correct version in PATH, or install and use a global.json

I don't really care about ProjectCracker etc understanding the new project format just yet - i just want this project to build and test cleanly both on developer machines and on AppVeyor CI

it's not a problem, can build current projectcracker with new tooling, same output

[cloudRoutine]

I've been porting over a lot of my projects to the new format and I've found using generators to be the easiest way to deal with them for now due to the lack of editor support.

• https://github.com/fsharp-editing/FSharp.Editing/blob/master/scripts/XLinq.fsx
• https://github.com/fsharp-editing/FSharp.Editing/blob/master/scripts/GenNetcore.fsx

I have it generate new msbuild15/netcore versions of the fsprojs before each build so it stays synchronized. Once the tooling support comes online we can consolidate into the nice svelte format and multiplatform build, but until then I think this is a pretty good stopgap.

[enricosada]

As a feedback, dont autogenerate fsproj.
Is easy to maintain here, are just two fsproj.

About editors support, vscode works, by quite some time now.
Vs on Mac will too, soon, if not already with new release.

Another is: dont use paket here with new fsproj, there is just one dep (fsharp.core). Can Ben pinned to exact version
Add Paket later. Leave thing simple for now, minimize unstable parts

[cloudRoutine]

• It's 6 projects (12 if you count the samples)
• vscode is finnicky at best and it's almost useless for this repo in particular, it reports all kinds of erroneous errors and can't supply proper completions because it can't evaluate the project properly
• it's great for the Mac users, but most of us are on windows
• paket is more stable than vscode's editor support, but that's not important

As a feedback, dont autogenerate fsproj

Why not? relying on people to remember to synchronize all of their changes seems much more error prone.
@enricosada what's your issue with automation?

[enricosada]

it reports all kinds of erroneous errors

i trust fsc for errors. it's f#, not that bad fix an compiler error.

can't supply proper completions because it can't evaluate the project properly

let's use it, and improve that so. i want to see why doesnt evaluate project properly.
FCS get all compiler args from ionide/FSAC, with normal project works ok. If it's just an issue of size, let's see bottleneck.

it's great for the Mac users, but most of us are on windows

i am too on windows, editors are not a limiting factor. more there because all work can be done in VS, and just fix api compatibility errors on netcore fsproj

@enricosada what's your issue with automation?

@cloudRoutine i trust automation but adding a tool/script is a tradeoff for maintanance, is not always a good thing. And i dont think is worth do it in this case.

In this case, sinchronize changes may be easier done extracting a .prop file (with all defines), shared between old and new fsproj. Cannot extract compile items too because ide doesnt support that in old fsproj afaik. Anyway that leave projects with just source files list pratically, not too bad.

Also i want to add proper multi targeting support, because will make things 1000th easier.

my feedback is not use that. but i not maintain this project, so np for me

[cloudRoutine]

@enricosada I'll let you handle the upgrade then

[dsyme]

@baronfel Thank you - I am so glad when I see project.json disappear.

[ghost]

@baronfel Thank you - I am so glad when I see project.json disappear.

@dsyme you rather have the verbose XML?

[forki]

@gentauro new MSBuild is slightly less verbose than old MSBuild and more importantly it's not dead like project.json ;-)

[dsyme]

@dsyme you rather have the verbose XML?

@gentauro No, I didn't mean that - I just want the churn in base tooling to stop.

[enricosada]

@gentauro there is no future for project.json, is deprecated, and works only on VS 2015 and with preview (1.0.0-preview2) of dotnet core.
The 1.0.0 rtm of .net core (and all 4 previous rc) works with msbuild, like VS 2017 does.
So is not like we can choose (but i think the new sdk is good, is using the msbuild language, but implemented better). Also project.json implementation was more immature than msbuild, so lots of bugs to fix