Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Support new sdk, the new fsproj of .NET Core Sdk #705
An important note: the .NET Core Sdk can build all target frameworks (net, netcore, pcl), so both .NET Framework and .NET Core projects.
FSC and related consumer (FSAC based ide) should support the new .NET Sdk, so for f# the new fsproj.
The workflow is the same, msbuild call
I miss some info.
Starting from the basics. What FCS need? What editors need? Previously that was done using project cracker, but maybe we can fix that without duplicate code/hacks.
What FCS need?
What ide/editors need?
/cc @tpetricek @dsyme @7sharp9 @latkin @vladima FCS team
(please add who is missing) and github teams maybe? :D
Some possibile solution
I'm not sure what that all means or how what the right distribution is.
The actual language targets don't live in the dotnet/SDK repo. The only targets in the SDK repo are about the app models (for netcore generating deps.json for eg) or setting defaults for frameworks. The actual language targets should live elsewhere (preferably closer to the compiler\build task). For C# for eg, the targets file that has CoreCompile lives in the roslyn repo next to the csc task itself and the SDK.targets file in the Dotnet/SDK repo just imports it with a relative path in MSBuild. If we can standardize on where the FSharp.targets are deployed relative to msbuild (which we already have for projects created in VS atleast), then the SDK.targets can add a check for .fsproj and pull in the FSharp.targets similar to how it pulls in the csharp.targets.
I don't fully understand all the places fsproj is used but in my mind, there should be one fsharp.targets instead of the two it looks like we have today (VF# repo and the fSharp.sdk) - should we be consolidating to one place or another?
Using the path relative to msbuild in VS has been a stumbling point for a bunch of people who didn't realize VS2017 changed the path structure relative to older versions. I've had to change the targets for almost every F# OSS project I work on.
<When Condition="$(TargetFSharpCoreVersion) >= 184.108.40.206 AND $(TargetFSharpCoreVersion) < 220.127.116.11 "> <PropertyGroup> <FSharpTargetsPath>$(MSBuildProgramFiles32)\Microsoft SDKs\F#\3.0\Framework\v4.0\Microsoft.FSharp.Targets</FSharpTargetsPath> </PropertyGroup> </When> <When Condition="$(TargetFSharpCoreVersion) >= 18.104.22.168 AND $(TargetFSharpCoreVersion) < 22.214.171.124 "> <PropertyGroup> <FSharpTargetsPath>$(MSBuildProgramFiles32)\Microsoft SDKs\F#\3.1\Framework\v4.0\Microsoft.FSharp.Targets</FSharpTargetsPath> </PropertyGroup> </When> <When Condition="$(TargetFSharpCoreVersion) >= 126.96.36.199 AND $(TargetFSharpCoreVersion) < 188.8.131.52 "> <PropertyGroup> <FSharpTargetsPath>$(MSBuildProgramFiles32)\Microsoft SDKs\F#\4.0\Framework\v4.0\Microsoft.FSharp.Targets</FSharpTargetsPath> </PropertyGroup> </When> <Otherwise> <PropertyGroup> <FSharpTargetsPath>$(MSBuildProgramFiles32)\Microsoft SDKs\F#\4.1\Framework\v4.0\Microsoft.FSharp.Targets</FSharpTargetsPath> </PropertyGroup> </Otherwise> </Choose> <Import Project="$(FSharpTargetsPath)" Condition="Exists('$(FSharpTargetsPath)')" />
Has worked decently for me although for some people XBuild doesn't seem to support
Why not set Environment variabales during the F# SDK installation and use that to find the targets like VS does?
or maybe set an envar per compiler version installation that way it'll be set to wherever the user decides and most of the guesswork will be out of the picture.
plus the envar can be aliased over in the process before the build starts if a different target set or a custom compiler build is needed for w/e reason.
Can someone give me a hand here please? I'd really, really appreciate help in getting this project to match the latest version of the .NET Core tooling - at least so it builds out of the box when that tooling is installed on the machine, and creates a good nuget package.
If someone who is up-to-date with .NET Core tooling coud update this project please I'd be hugely grateful....
there are two separate stuff:
I was working on this, on intellisense (with https://github.com/enricosada/dotnet-proj-info is pratically done, need refactor as lib) but i can do this migration now that 1.0 is out, if you think will unblock more.
i'll add more comments in #700
Added a working example using FSAC (called by vscode) in ionide/FsAutoComplete#53
There are also samples ready to use, see PR.
Now just restore Ian needed, project to project works, and in vscode also intellisense and F5 debug.
The integration to read fsproj (props/fsc args/p2p) exists as cli console app or library (lib is used by FSAC)
referenced this issue
Mar 16, 2017
as a note on progress with PR ionide/FsAutoComplete#53 , if someone want to review it (please! contains link to ready to use sample project too):
Is just FSAC code, so should work for everyone.
An update, released all required components:
and final FSAC integration (to replace projectcracker) wip in ionide/FsAutoComplete#55
in the PR there are info about how to test (with vscode), but is just FSAC code, so any client will do.