search

ionide / fstoml

Lightweight TOML based F# project file
MIT License
36 stars 7 forks source link

MsBuild and dotnet CLI integration #15

Closed Krzysztof-Cieslak closed 7 years ago

Krzysztof-Cieslak commented 7 years ago

OK, so this PR is following idea we've discussed in Slack channel. As suggested by @enricosada instead of generating full, standalone .fsproj file (or any other crazier ideas I had ;-) ) we put .fstoml file next to almost empty .fsproj file, and provide MsBuild targets to transform our .fstoml file to .targets file (which is full project file anyway, with resolved paket references, file list etc.) that we put in obj directory so it's automatically imported by MsBuild (just like additional files generated by dotnet restore etc.).

In such scenario .fsrpoj file looks something like that (and it's basically the same for every project):

<Project Sdk="FSharp.NET.Sdk;Microsoft.NET.Sdk; FsToml.Sdk" ToolsVersion="15.0">
  <ItemGroup>
    <PackageReference Include="FSharp.NET.Sdk" Version="1.0.0-beta-060000" PrivateAssets="All" />
    <PackageReference Include="FsToml.Sdk" Version="*"  />
    <DotNetCliToolReference Include="dotnet-compile-fsc" Version="1.0.0-preview2-020000" />
  </ItemGroup>
</Project>

We put next to it our standard .fstoml file [same names].

We would distribute targets responsible for generation as "sdk" which would mean it's automatically imported if package is added (not really sure how to do it but I assume that @enricosada can help with it). *.fstoml -> obj\*.targets generation is defined as pre-restore step so will happen whenever user runs dotnet restore - what IMO, is fine as Ionide / FSAC based tooling require running dotnet restore anyway [and I assume same will be true for VS when new project support will be added there].

I think this approach makes it super simple to integrate with any existing tooling and dotnet CLI which in the end is probably huge argument for adoption (and potential green light / support from Don). While personally I'd prefer something that can be parsed and resolved "natievly", without using MsBuild, I've came to conclusion (mostly thanks to experimenting with stuff that's on master branch) that it's not really possible (at least right now, with amount of time and work we can put into the project).

Another great news (or at least OK, depending on point of view) is that there are absolutely no dependencies on F#... we can use exactly same .fstoml file for C# or VB projects without any problem and it should just work with all their tooling out of the box. Again, personally I don't care too much, but Paket shows us that supporting multiple languages is good idea, and it would be good marketing for F# and the Community.

Krzysztof-Cieslak commented 7 years ago

Tests are not passing beacuse... there are not tests, I've removed them as they were connected with parts I've removed anyway.

To see that it works:

  1. Run build.cmd
  2. Go to samples\lib
  3. Run dotnet restore
  4. Run dotnet build or open in Code.
Krzysztof-Cieslak commented 7 years ago

CC: @alfonsogarciacaro @cloudRoutine @forki @matthid