Requirements going forward?

[dsyme]

@Thorium @smoothdeveloper @daniellitledev What are the requirements for this repo going forward?

At the moment #444 does

• Moves entirely to Microsoft.Data.SqlClient
• Formats code with Fantomas
• .NET 9 and .NET Standard 2.0 design time type provider (realistically will only run on .NET Core tooling)
• Ubuntu, Windows build and test
• Replaces WPF app used for "Sample" with a simple console app

If anything to do with .NET Framework is a requirement going forward this PR should probably be thrown away

[dsyme]

Looking at #441 (comment) there might be appetite for using a different package name for the major revision

[daniellittledev]

Hey @dsyme, great timing. I just picked this back up a few days ago and wasn't planning to comment yet, but here's a summary of where things stand from my end.

I attempted this migration previously but got bogged down trying to do too much at once, and the repository had accumulated a lot of legacy complexity that made it hard to make progress incrementally.

I have a lot of respect for @smoothdeveloper's commitment to legacy users, and the concern about migration paths is legitimate. That said, I think the requirement for dual-driver support inside a single package has, however unintentionally, stalled the project to the point where it's no longer compatible with current .NET tooling. The netfx.props workaround no longer works on GitHub Actions, and this has been unresolved for years. At some point, protecting existing users comes at the cost of the project having a future at all.

The good news is that a separate package is the migration path @smoothdeveloper has been asking for. Users on System.Data.SqlClient stay on the existing package. Users ready to move adopt the new one. Both coexist, no big-bang forced migration required.

To that end, I've forked the project as FSharp.Data.MicrosoftSqlClient. It is already working and published, targeting Microsoft.Data.SqlClient, with the core test suite passing. I also have plans to overhaul more of the repo: updating FAKE, moving to docker-compose for the test database, improved CI. I've already cleaned up the project files to target modern frameworks, added docker-compose for local dev, simplified builds, switched to standard dotnet pack etc.

I'd genuinely prefer this work land in the upstream repo as a new major version rather than live as a fork, but either way the goal is the same: a version of this library people can use on current .NET.

If there's appetite to bring it back into the main repo I'm happy to work toward that. Happy to share more detail on what's changed.

[dsyme]

@daniellittledev Makes total sense. I agree the dual-track means the project has stalled.

I'm happy to take a path where we bring your code back, using this repo and the FSharp.Data.SqlClient name, and bump the major version. It's normal in F# libraries now to do that (e.g. FSharp.Control.AsyncSeq made a breaking change in latest major version to bring compat with IAsyncEnumerable), and the previous version is available for those who want to maintain it as a 2.x version stream.

Would you be able to make a PR back to this repo with your changes (and no renaming) and we can compare with the engineering PR I submitted and work out how to integrate the best bits of each (or get an coding agent to work that out)? If you could apply fantomas to the code in the same way with same version we will be able to progress?

[dsyme]

@daniellittledev Can you also join fsprojects org please, thanks

[daniellittledev]

Great, thanks. A new major version sounds like the right call.

A few notes on where my fork currently sits and your PR:

• I've moved entirely to Microsoft.Data.SqlClient
• I'll add Fantomas formatting to match your PR so diffs are clean
• I've kept net471 support alongside netstandard2.0 and net8.0
• For tests, I'm planning to run only on Linux using Docker for the database, which simplifies CI and local dev considerably
• Agreed on replacing the WPF sample with a console app, I removed all the old samples.

One thing I'd like to raise: I changed the default namespace from FSharp.Data to FSharp.Data.SqlClient. Since we're doing a major version bump anyway, this feels like the right time to make that change. It's more descriptive and avoids polluting the top-level namespace. Keen to hear your thoughts.

There's still a few other things I need to do before opening a PR.

[smoothdeveloper]

@daniellittledev I actually didn't look into your fork, yes we need to bring the changes back in the main repository and have it ship both nuget packages.

One of the first thing I'll look at is experimenting with your fork in the main product I maintain that uses this library, assuming all still works on .NET Framework; it will give me good overview if there is anything that has broken.

Thanks a lot for consistently having pushed forward for supporting the new driver.

I changed the default namespace from FSharp.Data to FSharp.Data.SqlClient.

Yes there was already some work under way towards this, because namespace squatting of FSharp.Data seems inappropriate; since the existing package also define this namespace, users can make sure they have both open statements where they use the provider and the migration should be fine AFAIU.