target .NET Standard 2.0

[ctaggart]

Now that we are using .NET Core project files #73, thoughts on targeting .NET Standard 2.0 instead of net45? cc @jhugard @takemyoxygen

.NET Standard Versions

• https://github.com/dotnet/standard/blob/master/docs/versions.md
• https://blogs.msdn.microsoft.com/dotnet/2017/11/15/announcing-f-support-for-net-core-and-net-standard-projects-in-visual-studio/
• https://blogs.msdn.microsoft.com/dotnet/2017/08/14/f-and-net-core-roadmap-update/
• Multi-targeting does not work in VS VS 2017 15.5.0 - Multitargeting just plain doesn't work dotnet/fsharp#4084

[ctaggart]

See #78 where I made it so Froto.Parser & Froto.Serialization target netstandard2.0.

For the TypeProvider, I'd wait for this in 2018:

I’ll also share some of the things that I personally want to focus on in terms of what my team delivers:
Finalizing Type Providers as .NET Standard 2.0 components.

[ctaggart]

It looks like something may be doable after 15.6 ships. dotnet/fsharp#3864

F# Tooling RFC FST-1003 - Loading Type Provider Design-Time Components into F# Tooling
https://github.com/fsharp/fslang-design/blob/master/tooling/FST-1003-loading-type-provider-design-time-components.md

[ctaggart]

@takemyoxygen I'm not sure you up for it, but the ProvidedTypes from the TypeProviders SDK have changed a lot. I created a script to update to the latest #79, but it results in several errors.

[takemyoxygen]

@ctaggart I'll try to find some time to look at them this week.
So, now ProvidedTypes files are not managed by paket anymore?

[ctaggart]

@takemyoxygen, correct, I just committed them to the repository. paket is only used to download FAKE right now. I'm just PackageReferences that are built in to the new dotnet core project files instead of paket.

[cician]

Any chance it'll be worked on in the near future? I'd like to use Froto in .net core. I can use type providers from FSharp.Data just fine in .Net Core 2.1+VSCode&Ionide, but not Froto.

Thanks.

[7sharp9]

I’m actively using Froto in terms of the parser and serialiser but I have completely abandoned any use of type providers as they are too looking limiting in their use. Instead I am using precode generation to produce F# record types and their associate serialise and deserialiser functions for proto3.

…

On Sat, 12 May 2018 at 20:51, Maciej Kacper Jagiełło < ***@***.***> wrote: Any chance it'll be worked on in the near future? I'd like to use Froto in .net core. I can use type providers from FSharp.Data just fine in .Net Core 2.1+VSCode&Ionide, but not Froto. Thanks. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#76 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAj7ysFpcK4nTuWj5n6yzpV6DXQyFU4lks5txz02gaJpZM4RHPNV> .

[cician]

I tried updating the TypeProviders SDK files (someone please explain to me why these cannot just be a nuget package). I was able to make it at least compile as a netstandard library with a few adjustments, but there's more work to be done to make it work in .net core, but I can't figure out exactly what needs to be changed in project structure and packaging. The fsharp compiler still complains it cannot find any type provider classes. Should I submit a pull request with my partial changes?

Here's my fork: https://github.com/cician/froto-typeproviders-on-dot-net-core

p.s. I'm a newbie to F# and this would be my first PR to an open source project, so please go easy on me.

[cician]

I’m actively using Froto in terms of the parser and serialiser but I have
completely abandoned any use of type providers as they are too looking
limiting in their use. Instead I am using precode generation to produce F#
record types and their associate serialise and deserialiser functions for
proto3.

TypeProviders look pretty powerful to me, but kinda obscure and overly complicated to implement. Also having source code to inspect and eventually modify have its advantages. Do you recommend any codgen solution? Anything that integrates into the build system?

[7sharp9]

It’s integrated as a prebuilt step or just by running the generator tool pointing to a proto file. For me personally type providers have too many limitations, for example they cannot generate and F# specific types and they are often pretty awful to debug as they are so integrated into an IDE.

…

On Sun, 13 May 2018 at 18:37, Maciej Kacper Jagiełło < ***@***.***> wrote: I’m actively using Froto in terms of the parser and serialiser but I have completely abandoned any use of type providers as they are too looking limiting in their use. Instead I am using precode generation to produce F# record types and their associate serialise and deserialiser functions for proto3. TypeProviders look pretty powerful to me, but kinda obscure and overly complicated to implement. Also having source code to inspect and eventually modify have its advantages. Do you recommend any codgen solution? Anything that integrates into the build system? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#76 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAj7yrE8BhSFZKqorxbtL5hBn7B1oIxfks5tyG9AgaJpZM4RHPNV> .

[7sharp9]

@ctaggart As a note I extended the AST generation that you started and augmented it with somewhat, Im now using the provided types from this repo with some heavy modifications to generate record type with proto3 serialize/Deserialize functions.