Is it possible to define a build to use Mono/.NET for the backend, and Dotnet core for the FrontEnd?

[oscarvarto]

Description

I would like to use F# to build a website. First of all, I must say that I did see https://github.com/SAFE-Stack/SAFE-BookStore#getting-fsharpdata-in-the-backend

For the backend I would like to use Type Providers, for example,

• https://github.com/rspeele/Rezoom.SQL
• https://github.com/fsprojects/SQLProvider
• http://fsharp.github.io/FSharp.Data/

but, as far as I know, TypeProviders are not yet supported on .NET Core

I saw here https://github.com/Microsoft/visualfsharp/issues/3303#issuecomment-312966306 that it is possible "to use o enable type providers for .NET Core programming, as long as the type providers have been written as a cross targeting type provider" (See https://github.com/fsprojects/FSharp.TypeProviders.StarterPack#the-providedtypes-api---cross-targeting-type-providers), but I think that does not allow me to use something like Rezoom.SQL in the backend.

I also saw https://github.com/TheAngryByrd/dotnet-mono, and raised this issue https://github.com/TheAngryByrd/dotnet-mono/issues/14

I am a newbie with the technology stack used here, but I find it very attractive to use it for an actual business. That's why I need some help to modify the build (written with FAKE, paket and making a mixture of a lot of new technologies: Fable, Dotnetcore, Paket, Fake, docker, Suave, etc.). It is a lot of stuff to absorb at once.

Could you provide me with some guidance, please? On the other hand, is it realistic to expect that, not very far away from now, Type Providers will be supported on Dotnet core?

[forki]

There is already a full framework / mono project here in the sample. See https://github.com/SAFE-Stack/SAFE-BookStore/blob/master/test/UITests/UITests.fsproj - so in other words just change the target framework for the server project and the build should still work. But I heard that type providers don't work with dotnet sdk in full framework yet. /cc @cartermp

[isaacabraham]

We could definitely do a "classic" MSBuild project version as well - no need to use the dotnet sdk is there?

[forki]

No Isaac. That one is dead. Seriously. There won't be any fixes for old style any more. It's really dead and cold.

Am 24.09.2017 10:37 schrieb "Isaac Abraham" [email protected]:

We could definitely do a "classic" MSBuild project version as well - no need to use the dotnet sdk is there?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/SAFE-Stack/SAFE-BookStore/issues/172#issuecomment-331695902, or mute the thread https://github.com/notifications/unsubscribe-auth/AADgNIKz_26YEjt6H86nX1mY2vr03SO-ks5slhTIgaJpZM4PhxeP .

[isaacabraham]

Fixes for what? Back end Suave works fine with old school project format.

[isaacabraham]

Especially if there are problems with type providers then we need a story for old style projects, and ones that work in VS2015.

[forki]

For anything project system related in VS. And even ionide/rider won't fix with high priority. It's really really dead end.

Am 24.09.2017 11:19 schrieb "Isaac Abraham" [email protected]:

Especially if there are problems with type providers then we need a story for old style projects, and ones that work in VS2015.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/SAFE-Stack/SAFE-BookStore/issues/172#issuecomment-331697798, or mute the thread https://github.com/notifications/unsubscribe-auth/AADgNPQIWrj3E-wCb3zG_T4Jjnm1nZxFks5slh6WgaJpZM4PhxeP .

[isaacabraham]

But there's nothing needed to fix Everything should work in the old project system right now. Unlike the new project system.

[Krzysztof-Cieslak]

Unless it doesn't (for example ProjecCracker crashes) and we have no idea how to fix it ;-)

[forki]

Exactly. It doesn't. No fable. No nothing.

Am 24.09.2017 11:50 schrieb "Krzysztof Cieślak" [email protected]:

Unless it doesn't (for example ProjecCracker crashes) and we have no idea how to fix it ;-)

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/SAFE-Stack/SAFE-BookStore/issues/172#issuecomment-331699213, or mute the thread https://github.com/notifications/unsubscribe-auth/AADgNPsfLjOnw7lEn84Nl2sQ8wugGx6lks5sliXJgaJpZM4PhxeP .

[dsyme]

But I heard that type providers don't work with dotnet sdk in full framework yet.

The fundamental thing that doesn't "work" is loading a type provider into the F# compiler that executes on .NET Core.

There is a pretty straightforward workaround here : https://github.com/Microsoft/visualfsharp/issues/3303#issue-240393680

My understanding is that FSharp.Data works just fine, as long as you use the workaround. It is not however a fully tested scenario yet.

SQLProvider and Rezoom should be adjusted to be cross-targeting type providers and tested for use when targeting .NET Core (using the workaround above to compile).

[forki]

I think SQLProvider is already in the works for netstandard 2.

Am 24.09.2017 13:03 schrieb "Don Syme" [email protected]:

But I heard that type providers don't work with dotnet sdk in full framework yet.

There is a pretty straightforward workaround here : Microsoft/visualfsharp#3303 (comment) https://github.com/Microsoft/visualfsharp/issues/3303#issue-240393680

My understanding is that FSharp.Data works just fine, as long as you use the workaround. It is not however a fully tested scenario yet.

SQLProvider and Rezoom should be adjusted to be cross-targeting type providers and tested for use when targeting .NET Core (using the workaround above to compile).

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/SAFE-Stack/SAFE-BookStore/issues/172#issuecomment-331702526, or mute the thread https://github.com/notifications/unsubscribe-auth/AADgNMwd53TwH7vFyTmDgT7WYJ1oDm7eks5sljcYgaJpZM4PhxeP .

[dsyme]

I think SQLProvider is already in the works for netstandard 2.

@forki OK, that's great news. We should make sure and end-to-end scenario is under test.

@isaacabraham The only interaction with project format is that dotnet executes the F# compiler using .NET Core by default (msbuild executes using Mono/.NETFramework), which exposes the user to the fact that type providers aren't supported in that scenario. It is much better to apply the workaround linked rather than revert back to the old project format.

[isaacabraham]

SQLClient type provider also needs updating. This type provider isn't compatible with F#4.1 compiler - nothing to do with .net core or the new project format.

I'm not sure how many others are impacted by 4.1.

[isaacabraham]

I'm just not sure if we really want to be saying "new project format or the highway".

[forki]

But that's reality. It's time to face it and probably the only way out of current compatibility issues.

Am 24.09.2017 13:45 schrieb "Isaac Abraham" [email protected]:

I'm just not sure if we really want to be saying "new project format or the highway".

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/SAFE-Stack/SAFE-BookStore/issues/172#issuecomment-331704590, or mute the thread https://github.com/notifications/unsubscribe-auth/AADgNLfKMF6EvSGZQLG26bxcXP6GLmieks5slkC9gaJpZM4PhxeP .

[Krzysztof-Cieslak]

The fundamental thing that doesn't "work" is loading a type provider into the F# compiler that executes on .NET Core.

I believe that's the only thing that doesn't work, and there is workaround for it. From tooling point of view, all tools use Full Framework of FCS so TPs should be handled in editors without any problem.

In general, I think we should go with new format, the faster people will move to it, the faster we will leave current terrible state. New project format seems to work better in Ionide, new Forge scaffolds projects with new fsprojs, people seems to like even dotnet new experience.

The only problem is general lack of support in VS for new fsproj... but that's problem anyway since Fable uses new fsprojs, no matter what will be the choice for a backend.

[oscarvarto]

@dsyme Here https://github.com/Microsoft/visualfsharp/issues/3303#issue-240393680 you are recommending to modify the .fsproj to have something like

 <PropertyGroup>
    <IsWindows Condition="'$(OS)' == 'Windows_NT'">true</IsWindows>
    <IsOSX Condition="'$([System.Runtime.InteropServices.RuntimeInformation]::IsOSPlatform($([System.Runtime.InteropServices.OSPlatform]::OSX)))' == 'true'">true</IsOSX>
    <IsLinux Condition="'$([System.Runtime.InteropServices.RuntimeInformation]::IsOSPlatform($([System.Runtime.InteropServices.OSPlatform]::Linux)))' == 'true'">true</IsLinux>
  </PropertyGroup>  
  <PropertyGroup Condition="'$(IsWindows)' == 'true'">
    <FscToolPath>C:\Program Files (x86)\Microsoft SDKs\F#\4.1\Framework\v4.0</FscToolPath>
    <FscToolExe>fsc.exe</FscToolExe>
  </PropertyGroup>
  <PropertyGroup Condition="'$(IsOSX)' == 'true'">
    <FscToolPath>/Library/Frameworks/Mono.framework/Versions/Current/Commands</FscToolPath>
    <FscToolExe>fsharpc</FscToolExe>
  </PropertyGroup>
  <PropertyGroup Condition="'$(IsLinux)' == 'true'">
    <FscToolPath>/usr/bin</FscToolPath>
    <FscToolExe>fsharpc</FscToolExe>
  </PropertyGroup>

as a workaround to use type providers. Is the above useful for generative type providers as well? https://github.com/rspeele/Rezoom.SQL "integrates with the F# compiler via a generative type provider"

@forki @isaacabraham @Krzysztof-Cieslak @matthid @dsyme Thanks for your time and patience. I'm happy to see the willingness to help.

[dsyme]

Is the above useful for generative type providers as well?

To some extent. The type provider must be authored as a cross-targeting type provider, but these are currently non-generative. We could fix that.