Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Target .NET Core 2.0 #270

Closed
panesofglass opened this issue May 23, 2017 · 9 comments
Closed

Target .NET Core 2.0 #270

panesofglass opened this issue May 23, 2017 · 9 comments
Labels

Comments

@panesofglass
Copy link
Contributor

panesofglass commented May 23, 2017

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
Copy link
Contributor

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
Copy link
Contributor Author

panesofglass commented Jun 29, 2017

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
Copy link
Contributor

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
Copy link
Contributor

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
Copy link
Contributor

dsyme commented Feb 28, 2018

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
Copy link

@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
Copy link
Contributor

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

@panesofglass
Copy link
Contributor Author

Looks like #314 will resolve this.

@vasily-kirichenko
Copy link
Contributor

Implemented in #314

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

6 participants