Target .NET Core 2.0

[panesofglass]

Description

Provide an updated package that supports .NET Core 2.0. This is not yet ready but getting closer. See dotnet/fsharp#3069. I'm happy to help contribute to this.

Note that support for .NET Core means reverting SqlEnumProvider to an erasing provider, or cutting this from the .NET Core version, as generative providers will not be supported. What should be done in this case? As a user of SqlEnumProvider, I would prefer that it revert to an erasing provider, at least for the .NET Core target. I'm not sure whether others are using this for generating true enums or not at this time.

Questions:

1. Is anyone using the generated System.Enum feature?
2. Would changing this to an erasing provider adversely affect any cross-language use?
3. Anything else not addressed by the first two questions?

[dsevastianov]

It sounds feasible, though it would be great if other users of SqlEnumProvider chimed in, especially those calling generated types from other .Net languages. Jet.com should be fine with this change. I would rather make this change across the board and not fork for specific target.

[panesofglass]

At Tachyus, we use SqlEnumProvider to generate something like:

module Constants =
    [<Literal>]
    let ``Some Value`` = "Some Value"
    [<Literal>]
    let ``Another Value`` = "Another Value"

We don't have any use of generating true enumerations, handy as that is. I'm also not aware of any requirements for the [<Literal>] attribute, e.g. to use as values in an attribute, though that is also a very handy feature.

[dsevastianov]

I believe @dmitry-a-morozov implemented this mostly for C# compatibility, and I am not aware of any usages of this feature in the wild. I am fine with the switch.

[samhanes]

I made an attempt to migrate the project to target netstandard 2.0, but I ran into a brick wall when I realized that SqlCommandBuilder isn't yet available. It looks like it will be added in netstandard 2.1, so I'll give it another shot once that has been released.

[dsyme]

I wrote up notes of what it means to move an existing type provider to support both .NET Standard and loading into .NET Core-based F# tooling https://github.com/fsprojects/FSharp.TypeProviders.SDK#updating-a-type-provider-to-be-suitable-for-use-with-the-net-sdk

However it looks like SqlCommandBuilder and .NET Standard 2.1 will be needed from the above

[davidtme]

@samhanes When you migrated the project target netstandard 2.0 did you upgrade ProvidedTypes.fs to the latest FSharp.TypeProviders.SDK? I've hit a few problem and I'm just wondering if you have already solve them.

[vasily-kirichenko]

WIP #291, however, it's not going very well so far.

[panesofglass]

Looks like #314 will resolve this.

[vasily-kirichenko]

Implemented in #314