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 https://github.com/Microsoft/visualfsharp/issues/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]

https://github.com/Microsoft/visualfsharp/issues/2406#issuecomment-335987927 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 [email protected] 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 https://github.com/rspeele/Rezoom.SQL/issues/15?email_source=notifications&email_token=AAMP4WVLP47NU4AVD6PIE3DPWAMTHA5CNFSM4DXH5WVKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODVWQOOQ#issuecomment-493684538, 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.

[Swoorup]

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

[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: https://github.com/rspeele/Rezoom.SQL/issues/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.