Any plan to support .net core 2

[darting]

Hi there,

Any plan to support .net core 2

Thanks

[rspeele]

I would like to eventually support .NET Core, but do not see it happening soon.

As a generative type provider, Rezoom.SQL is waiting for full support for type providers in .NET core.

[darting]

From this issue dotnet/fsharp#3303 seems we can use Type providers in .net core as long as we change the fsc path in project file?

[rspeele]

I believe that workaround is only for erasing type providers, based on the wording "To convert an erasing type provider to a cross-targeting erasing type provider [... rest of instructions]".

[ashalkhakov]

What is needed to convert a generative TP to an erasing one?

I don't have any experience implementing TPs. But I would like to use Rezoom.SQL on very, very old mobile devices. The kind of devices where raw SQL queries are crucial for performance, and no ORM will cut it.

[rkosafo]

Apparently a lot of work. Looks like a rewrite but not very sure. @rspeele I also have no experience in type providers but could help if pointed in the right direction.

[zaaack]

dotnet/fsharp#2406 (comment) Looks like dotnet core's generative type provider support has made big progress, not sure it's stable now, but just need more weeks?

[AndrewTakker]

@rspeele Any progress in a .net core?:)

[kaeedo]

It seems that with the latest .Net Standard release, Type Providers are now fully supported:
https://blogs.msdn.microsoft.com/dotnet/2018/05/08/f-language-and-tools-update-for-visual-studio-2017-version-15-7/

[rspeele]

Hey guys,

I finally got the motivation to attempt the upgrade. Well, also after I updated VS I lost the project template for .NET Framework F# projects (thanks...) which I take as a signal that I am well behind the times and perhaps the ecosystem is stabilizing.

I've released new versions of LicenseToCIL, FParsec-Pipes, and Rezoom targeting .NET Standard 2.0. These are my other projects that Rezoom.SQL depends on

I think I'm getting close on Rezoom.SQL, but I've hit a bit of a roadblock.

On .NET Framework, I had to do something a bit hacky to get the dependencies to load in "design mode" (i.e. from the compiler or from VS intellisense).

On .NET Standard, the same approach won't work. When I make a .NET core project, the dependencies don't even get copied to the solution folder. They live in ~/.nuget. So my .NET Standard version of the codebase builds fine, but when I try to reference the type provider from another project, it blows up because it can't even find Rezoom.SQL.Mapping and Rezoom.SQL.Compiler... let alone the NuGet dependencies like FParsec.

Maybe I should just change that AssemblyResolver hack so it can go rooting around in ~/.nuget for those. Seems pretty ugly though.

Anybody know what the best practice is for type providers that depend on other NuGet packages?

Edit: I also hacked up something here that's none too pretty. Better ideas are welcome.

[piaste]

@rspeele Maybe see if the way FSharp.Data.Npgsql does it could work for you? It's .NET Standard compatibile and it depends on Npgsql at compile time, but at a quick glance it doesn't seem to rely on assembly-loading code.

[nojaf]

Maybe @KevinRansom has some ideas, I believe he worked on migrating type providers to dotnet core. I could be wrong though.

[nojaf]

Perhaps add a resolution path property similar how SQLProvider for MySQL needs this.

[rkosafo]

@rspeele

How far with this? Is it stable enough for testing?

I just tried it but got the issues below. Now sure if I'm doing something wrong or it's currently not yet ready for .net core

I was testing with sqlite. Issue were as follows

1. Nuget complained System.Data.Sqlite is not available on .net core so is using 4.7.1
2. type MyModel = SQLModel<"./"> is complaining about a missing FParsecCS v1.0.0.0. Couldn't find that library on nuget
3. No rzsql.json was added to the project. I added one but since it was not auto added, I wondered if there was a new approach towards specifying the config.

Do point me in the right direction if there is any assistance with respect to helping with the upgrade to .net core.

Thanks,
R.

[rspeele]

I haven't been working on it for quite some time. My workplace is still not using .NET core or .NET standard so I haven't gotten much hands-on time with it and have been busy with other hobbies in my free time.

FParsecCS is a .dll that comes with the normal FParsec package (specifically, it is part of FParsec written in C# for performance reasons).

The "standard" branch is as far as I got. I got stalled on packaging, but I can't remember whether or not I got it working using it locally (i.e. dropping assemblies into place instead of using nuget).

[bessgeor]

@rspeele

Is there any progress on netstandard version?

[mrkaspa]

Is there any progress on this?

[rkosafo]

I've trying to continue the work done on the standard branch for a while now.

So far, with some hacks that need to be cleaned up,

type M = SQLModel<"."> works. Calling the migrate however fails

let migrate () = 
  M.Migrate
    { Migrations.MigrationConfig.Default with
        LogMigrationRan = fun x -> printfn "Ran: %s" x.MigrationName }

migrations is null when this function is called

[<Extension>]
 type MigrationExtensions =
    [<Extension>]
    static member Run
        ( migrations : string MigrationTree array
        , config : MigrationConfig
        , backend : unit -> IMigrationBackend
        ) =
        use backend = backend()
        MigrationUtilities.runMigrations config backend migrations

@rspeele Under what circumstances is migrations null? Am I missing something?

[rspeele]

The migrations parameter comes from a private static field on the generated M type.
That field is supposed to be initialized by a static constructor (aka "type initializer").

https://github.com/rspeele/Rezoom.SQL/blob/master/src/Rezoom.SQL.Provider/TypeGeneration.fs#L366

The static constructor's initialization code looks like it couldn't possibly leave the field null, since it sets it to Expr.NewArray(typeof<string MigrationTree>, ...stuff) and even if the ...stuff wasn't right, it should at least end up as a non-null array.

So I wonder if static constructors in generative type providers aren't supported in NET Core? migrations being null only makes sense to me if that static ctor is never running.

If that is the issue, it could be changed so instead of a static constructor initializing a field, it's just a generated static method that returns the migrations array fresh each time -- I would think most if not all programs would only invoke M.Migrate once, so no sense keeping that data in a static field. Then change the two places that use that Expr.FieldGet to call the method instead.

[rkosafo]

@rspeele Thanks for the response. The constructor appears to be called (at least from the additional logs) but the field was still null. I changed it to a ProvidedProperty and it is working now.

SQLModel is working now. The database and tables are created when Migrate is called. SQL is however failing with The type provider 'Rezoom.SQL.Provider.Provider' reported an error: Operation is not valid due to the current state of the object.

I think it has to do with some missing libraries. I've created a temporary folder where I add any library it reports missing. Will continue supplying all missing libraries and report back if there are any strange errors I do not understand.

[rkosafo]

Finally got both SQLModel and SQL to work. Also, added a hack to load the libraries. No need for the temporary folder to load the libraries. Further testing needed

Use the steps below to help test until the code is sanitized and nuget packages created

Create new .net core project
Install libraries:
	`Rezoom 1.0.0`
	`LicenseToCIL 1.0.0`
	`FParsec-Pipes 1.1.0`
	`System.Configuration.ConfigurationManager`
	`System.Data.SqlClient`
Install new Provider libraries
	`Rezoom.SQL.Compiler`
	`Rezoom.SQL.Mapping`
	`Rezoom.SQL.Provider`
Add the additional files
  Add `rzsql.json`
  Add `V1.Model.sql`
Add code to test

PS:
I had to change the product version in FParsec-Pipes and Rezoom so they match the nuget numbers. I was getting .... The type initializer for ... threw an exception. If so, I've attached FParsec-Pipes and Rezoom that fixes the Product version.

Files:
Rezoom,FParsec-Pipes.zip
Rezoom.SQL.Provider.zip

Also, I've only tested on TSQL.

@rspeele
The codes are at

https://github.com/rkosafo/Rezoom.SQL/tree/standard
https://github.com/rkosafo/FParsec-Pipes
https://github.com/rkosafo/Rezoom

Should I create the pull requests or will you check the code from the fork?

[rspeele]

This is fantastic. Thank you so much. I looked through the code earlier today and the only comment I was going to make was to remove the tryLoadFromLibFolder function, which you did anyway before making your PR.

I guess the only things now are:

1. Testing on other backends
2. NuGet packaging

I am going to go look at the PRs on Pipes and Rezoom now.

[Swoorup]

Any updates on this? What is required atm?

[rkosafo]

@Swoorup It is largely complete but when FParsec-Pipes was updated to version 1.1.1, we get the error below. Currently looking for the meaning and solution to this and support for .net standard 2 will be done.

System.TypeInitializationException: The type initializer for '<StartupCode$Rezoom-SQL-Compiler>.$Rezoom.SQL.Compiler.Config' threw an exception. ---> 
System.IO.FileLoadException: Could not load file or assembly 'FParsecCS, Version=1.0.3.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. A strongly-named assembly is required. (Exception from HRESULT: 0x80131044)
   at <StartupCode$Rezoom-SQL-Compiler>.$Rezoom.SQL.Compiler.Config..cctor()
   --- End of inner exception stack trace ---
   at Rezoom.SQL.Compiler.Config.Parser.get_config()
   at Rezoom.SQL.Compiler.Config.parseConfig(String sourceDescription, String source)
   at Rezoom.SQL.Compiler.Config.parseConfigFile(String path)
   at Rezoom.SQL.Compiler.UserModel.Load(String resolutionFolder, String modelPath)
   at Rezoom.SQL.Provider.UserModelCache.Load(String resolutionFolder, String modelPath)```

[rspeele]

Let me know if you need write access to fparsec-pipes and/or the .snk file for a release build.

…

On Sat, May 18, 2019 at 11:16 AM Richard ***@***.***> wrote: @Swoorup <https://github.com/Swoorup> It is largely complete but when *FParsec-Pipes* was updated to version 1.1.1, we get the error below. Currently looking for the meaning and solution to this and support for .net standard 2 will be done. System.TypeInitializationException: The type initializer for '<StartupCode$Rezoom-SQL-Compiler>.$Rezoom.SQL.Compiler.Config' threw an exception. ---> System.IO.FileLoadException: Could not load file or assembly 'FParsecCS, Version=1.0.3.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. A strongly-named assembly is required. (Exception from HRESULT: 0x80131044) at <StartupCode$Rezoom-SQL-Compiler>.$Rezoom.SQL.Compiler.Config..cctor() --- End of inner exception stack trace --- at Rezoom.SQL.Compiler.Config.Parser.get_config() at Rezoom.SQL.Compiler.Config.parseConfig(String sourceDescription, String source) at Rezoom.SQL.Compiler.Config.parseConfigFile(String path) at Rezoom.SQL.Compiler.UserModel.Load(String resolutionFolder, String modelPath) at Rezoom.SQL.Provider.UserModelCache.Load(String resolutionFolder, String modelPath)``` — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#15>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAMP4WQMI77DG5VWDDKCZNDPWAMTHANCNFSM4DXH5WVA> .

[rkosafo]

@rspeele It is interesting but

1. Using the debug build of FParsec-Pipes works. The FParsecCS error appears with the signed version with FParsec-Pipes. Still looking into why. Is it possible to publish an unsigned version of FParsec-Pipes?

2. Rezoom 1.0.0 gives the error below because of the wrong version number (0.4.2). When it is replaced with a build that corrects it, everything works. When will you publish 1.0.1?

System.IO.FileLoadException: 'Could not load file or assembly 'Rezoom, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null'. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)'

I think we are good to go with .net standard if the above are resolved.

[rkosafo]

Right, now there is no way to build a F# .Net framework console application with Visual Studio 2019 at least for new projects and with mono on linux, I ran into other bugs.

I might take a look, but I am an F# newbie

What are these bugs that are preventing the build?

[Swoorup]

VS 2019 has no option to build a console .net core app with F# (option exist for C#) and with mono I run into this bug: #20

[AndrewTakker]

VS 2019 has no option to build a console .net core app with F# (option exist for C#) and with mono I run into this bug: #20

Try to use jebrains rider

[Swoorup]

VS 2019 has no option to build a console .net core app with F# (option exist for C#) and with mono I run into this bug: #20

Try to use jebrains rider

I did, but that means I am locked to windows platform, since mono has an issue.

[Swoorup]

I upgraded the pipe library to use .Net Standard 2.0 and latest fsharp.core. Although I am not sure that would help the problem here: rspeele/FParsec-Pipes#14

[rkosafo]

FParsec-Pipes supports .net standard 1.6. I'm windows only for now so sure but does .net standard 1.6 not work on Mac and Linux?

[Swoorup]

I think it should work with mono. I only looked at your branch targeting standard 2.0 and thought making use of .Net Standard 2.0 might make it consistent and reduce potential issue. Also it didn't seem to make sense to multi-target the parsec-pipe library since standard is meant to be a unifying point.

Also upgraded the package to use FSharp.Core 4.6.2

I am still trying to work out how to link everything (Rezoom) locally so I can get it to work locally without Nuget. Seems like to publish a release build I need a snk file or something.

[FoggyFinder]

any news?

[rspeele]

I published Rezoom 1.0.1 which should fix the version # problem.
I have also published an unsigned version of FParsec-Pipes: https://www.nuget.org/packages/FParsec-Pipes-Unsigned/

[Swoorup]

Lets now merge all .net standard stuff in 👍 😄

[rkosafo]

I published Rezoom 1.0.1 which should fix the version # problem.
I have also published an unsigned version of FParsec-Pipes: https://www.nuget.org/packages/FParsec-Pipes-Unsigned/

Cool. Will test and feedback.

[lem0n4de]

Thanks for this project. Is there anything I can do this to speed this issue?

[Neftedollar]

@rkosafo do you need some help?

[rkosafo]

Sorry about the delay. Was locked up in a project.

@Neftedollar Any assistance will be appreciated.
@rspeele Updated the libraries and everything is working fine now. Sample works correctly. Changes have been pushed. Currently checking to see if anything needs cleanup. Please check and advice if it can be published.

[realvictorprm]

Any news? 😸

[Swoorup]

Since, there's issues testing this locally (requiring nuget), it allows to use github repositories directly instead of nuget feed, how do you feel about upgrading to use paket, @rspeele @rkosafo ? I can create a PR for it.

[cmeeren]

Any news on this? 😊 I'm wondering if Rezoom.SQL is likely to ever see support for .NET Core. I'm having some trouble with SqlClient and looking for alternatives, but it seems that it's currently the only TP that supports raw SQL (as opposed to e.g. SQLProvider) and works on .NET Core - to some extent.

[rkosafo]

@cmeeren .net core support is working but only if you use the standard branch. The main branch has paket support. Only 2 things are essentially left

• merge the standard branch into master
• publish the nuget package.
  Sorry there is no timeline for this (will do well to work on it this month) but I can share with you the steps in getting it to work with a .net core project.

[cmeeren]

I can share with you the steps in getting it to work with a .net core project.

Thanks, but this is for production use, so I'll have to wait until it's released as a NuGet package anyway. I'll wait patiently and will continue to use SqlClient for now. 👍

[cmeeren]

Hello again, hope you are doing well.

I just checked and it seems there are no merge conflicts for merging standard into master. If that's all it takes (plus deploying to NuGet), isn't this pretty much as simple as flicking a switch or two? Anything I can do to help speed it along?

[chriserik]

@rkosafo Can you share the steps to use it with .NET core? Your library might be exactly what we are looking for and I need to make a decision soon so I'd be willing to try this out even if there is no NuGet package available yet. Thanks!

[JaggerJo]

@chriserik was trying to do the same and ended up with https://github.com/JaggerJo/Rezoom.SQL ... It works fine on MacOS and Linux (and I'd guess Windows).

[chriserik]

Nice, thanks @JaggerJo ! I could get a sample project to build and run with your fork although I now have major issues with the F# tooling on OSX (Ionide / fsac crashes), but this does not belong here...

[nicola-zanardi]

Hi guys,
first of all thanks for all the work devoted to this library. Looks extremely interesting and I am looking forward to try it out.

I can use the latest standard branch, but would be awesome to have it on nuget

Thanks in advance!

[FrigoEU]

I'd love to use this with .net core 2. It seems the standard branch is supporting this. Could anybody give me some pointers on how to configuration paket.dependencies and paket.references to use the standard branch?

Thanks for any advice!