dotnet core ready?

[lw-schick]

can i use this api with dotnet core?

[mariomeyrelles]

It seems that F# is still on alpha on dotnetcore. Maybe it's too early to consider this option.

[TheDarkTrumpet]

I dunno, the whole dotnetcore thing is in preview 2 at the moment, and F# seems to work quite well from my messing around with. Not sure how much work it would take to get this ready for the dotnetcore version.

[Thorium]

There is no direct external Nuget references in this package. However it is using a lot of dynamic loaded database connection libraries that are not supporting .NET Core.

Also getting any type provider (using usually the ProvidedTypes-head.fs file) to compile with .NET Core can be a challenge. This may be solved by fsharp team as it's a common problem for all typeproviders.

I did some initial testing but it seemed that the .NET Core is not mature enough to be bothered.

[Banashek]

Any updates on this? Definitely interested in using SQLProvider with dotnet core.

[nojaf]

Will .NET Core 2.0 change anything here?

[Thorium]

We are using directly https://github.com/fsprojects/FSharp.TypeProviders.StarterPack
They will make the support for .NET Core earliest at netstandard 2.0 as there is not yet enough interfaces supported at netstandard 1.6.

[Thorium]

Hi .NET-core-pros, I have one more question:
Does the development IDE has to run on .NET Core to actually develop to .NET Core, or are they (like Visual Studio) still running on something else?

Actually maybe we could support .NET Core already: This is erasing type provider, the only time we need ProvidedTypes is design-time SqlDesignTime.fs and not runtime. Could we could just have .NET Core as a build target, where we would exclude the design time from that build target?

So that you would build your project with normal intellisense and then just run dotnet.exe to actually do the release-build of your program to run in .NET Core? Would that work?

(There may still be problems with support of reflection, transactions, etc.)