Steps to support project file targeting full .net framework?

[Zaid-Ajaj]

.NET Core is cool and all, but getting started with Fable requires a steap learning curve and installing many things (dotnet sdk, runtime). I am sure a lot people are still using VS 2015 (or 2013, 2010) and are happy with it.

What are the challenges of making this happen?

• Parse the old project file (already done in v0.7.x)
• Use paket (AFAIK, paket already works with the "old" project file, and VS 2015 has support for paket too)
• Publish Fable.Tools as a nuget package where the daemon is a console app in tools directory that, according to nuget, "the path of the tools directory will be added to PATH"

[alfonsogarciacaro]

I'm sorry but I won't be able to dedicate any time to this, if anyone is interested in Fable 1.0 supporting the old project format they'll have to work on that feature themselves. It's already hard to make Fable work with the current set of tooling and we're too small a team to cover too many scenarios. Right now, VS for Windows is the only editor that hasn't supported the new .fsproj yet, and it will soon. I don't think dedicating development resources to support the old format is worth the effort 😕

Parse the old project file (already done in v0.7.x)

Please note this only worked with source files and non-conditional references, this forced users to manually add references to libraries.

Use Paket

AFAIK, Paket with the old project works by injecting a lot of conditional items in the .fsproj, not with the .fsproj.references file we're using right now. We would have to interact with Paket in a completely different way.

Publish Fable.Tools as a nuget package where the daemon is a console app in tools directory

I have never used this so I'm not sure how it could work.

[Zaid-Ajaj]

I think I made the wrong "issue" here, this should have been a question 😄

I had some thought about a different workflow and I wanted to give it a try on my own but I was not sure what is needed for this to work in theory.

Is it correct that nuget packages published with dotnet pack can't be used in net45?

[ctaggart]

Is it correct that nuget packages published with dotnet pack can't be used in net45?

No, you can target net45 as one of your targets.

[Zaid-Ajaj]

@ctaggart Nice, that's good to know. Thank you!

[enricosada]

@Zaid-Ajaj while new sdk (new fsproj used in fable) works the same in mono/msbuild.exe/dotnet cli (from fsharp.net.sdk >= 1.0.3 , is not yet support in VS 2017.
So you can target net45 (can target multiple target in same fsproj, with new sdk btw), but it doesnt work in VS anyway. Is not the .net core, the issue, is the new sdk and project format.
Old sdk as lot more problem in crossplatform support and is a pain for maintaners (just read the project info is a pain and has issues, as @alfonsogarciacaro said)

In the VF# roadmap, the expected date is July update, when VS 2017 will support new sdk in Visual F#.

So instead of do lot of work to support old sdk (pain to maintain two implementations) who is getting obsolete really soon, is better ihmo to wait a bit (the crossplatform support atm with fable and editors like vscode/vsonmac is awesome) until july and just improve the VS with net4* later, using new sdk

So eventually the msbuild .net runtime (mono/vs/netcore) will matter less (thx to new sdk), probably will be transparent for users (for sure for windows users), but atm without VS support, is useless to spend time ihmo, because experience (for users) need to be polished and the maintence (for fable team) need to be minimized.
New sdk will helps, but need more time. Old sdk is a time sink, who is getting obsolete anyway in .net world.

[Zaid-Ajaj]

@enricosada The main reason I was thinking about doing this, is to streamline the getting started experience for newcomers. Making it easy for people to use what they have now (vs2015 or lower) to play around with fable. I am using vs code now with dotnet core and that works fine. But this was after a series of frustrating tries to get it working in the first place on my machine. I couldn't even install VS2017 on my machine which is another reason that got me thinking about this.

However, after reading your feedback I have to agree that focusing the dev resources on the new sdk is a better and waiting a bit will be worth it.

Thanks again for your time on this.