-
Notifications
You must be signed in to change notification settings - Fork 71
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
[WIP] Netstandard 2.0 #291
[WIP] Netstandard 2.0 #291
Conversation
We need to make sure we don't preclude usage from FSI dotnet/fsharp#3309 |
@smoothdeveloper I think it will be version 2.0 with no FSI for now. |
We need to support multiple targets, netstandard doesn't work at all with VS2015, FSI. I don't know what is the best way to deal with that but it seems having separate fsproj could be a solution. I understand that having the provider work on .net core is a priority but we need to keep the library working for full framework and scripting scenarios. |
@smoothdeveloper |
Current status:
note the Build has different errors like this:
(it's all on MacOS) |
…library for both (untested)
…target New sdk format: add net462 target
# Conflicts: # src/SqlClient/packages.config
remove FSharp.Configuration
OK, the problem with loading System.Configuration was my mistake - an old FSharp.Configuration was referenced, which does not support netstandard, however 2.0.0-alpha works ok, it does not support AppConfig TP, so I've dropped the reference at all. Now I have different errors at design/compile time:
|
So, the TP is trying to load the and fails with the above error. There is a (full? impl?) assembly in the nuget cache: It seems it should load this one. @dsyme could you please help? |
/cc @baronfel |
|
…also pin sdk version using global.json
don't override user install of 2.1.200 dotnet sdk if already exists.
* remove net462 targets from build.fsx * add workaround from https://github.com/fsprojects/FSharp.TypeProviders.SDK#making-a-net-standard-20-tpdtc to SqlClient.fsproj
@Thorium thanks!
Yes, some dlls are copied to Why not to
How so?? I see all the providedtypes.xxx files are included:
How do you achieve this if you've copied |
Sorry, you are correct, I replied by the earliest design, which have been changed after ProvidedTypes.fs updates. :-) |
@Thorium thanks... Design time still works ok, but building now broken:
Ideas? |
Build of the type provider or build of the project that is using the type provider? |
Design-time is often cached (and depends a bit are you using VS2017 or VS code), so I would trust build more than design-time. |
The project that uses the TP. |
@Thorium I've looked closer to SQLProvider sources. Do I understand right that
|
So as far as I know the points 1 and 2 are just historical coincidences. |
Some general things:
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would almost like to see some kind of resolver in TypeProvider SDK level, as this is so common, almost all type providers need at least some references.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would almost like to see some kind of resolver in TypeProvider SDK level, as this is so common, almost all type providers need at least some references.
# Conflicts: # .paket/Paket.Restore.targets # .paket/paket.bootstrapper.exe # build.cmd # build.fsx # paket.dependencies # paket.lock # src/SqlClient.Samples/WebApi.Controllers/App.config # src/SqlClient.Samples/WebApi.Controllers/paket.references # src/SqlClient.Samples/WebApi/paket.references # src/SqlClient.Samples/WebApi/web.config # src/SqlClient.Samples/WpfDataBinding/App.config # src/SqlClient.Samples/WpfDataBinding/paket.references # src/SqlClient.Tests/Lib/App.config # src/SqlClient.Tests/Lib/Lib.fsproj # src/SqlClient.Tests/SqlClient.Tests.NET40/SqlClient.Tests.NET40.fsproj # src/SqlClient.Tests/app.config # src/SqlClient.Tests/paket.references # src/SqlClient/AssemblyInfo.fs # src/SqlClient/Configuration.fs # src/SqlClient/paket.references
related: dotnet/fsharp#5115 |
This has been silent since the middle of May. Is it realistic to hope for .NET Core support, or should I look elsewhere for a .NET Core SQL type provider (or simply stick to Dapper)? |
This has been silent since the middle of May. Is it realistic to hope for .NET Core support? |
I personally don't have plans to finish it, sorry. Type providers on Core is a super fragile mess. |
@cmeeren, @lessismore1 (@mauriciomagni), there will be realistic hope once someone who is more familiar with TP SDK and the new dotnet core tooling can give it a serious look. I'm myself just starting to try the new tooling, but I'm not yet concerned with using the TP on dotnet core, nor am I at ease with TP SDK stuff. Alas, MSSQL is not the kind of stuff I deal with much in my freetime, akin to active usage of C# in that regard 😃. If someone is willing to give it another shot, I'll be eager to help however I can, and if I eventually need the provider for my work, I'll commit more efforts, but it is not happening yet. Maybe MS can actually pour in some resources, this library is such a great illustration of type providers, targetted toward their covetted MSSQL cash cow, may be worth to ping @cartermp & @dsyme to see if they would be able to give it a nudge. |
TPs on. Net core are in good shape now, there are basically no known remaining bugs in the TPSDK and packaging/publishing should be straight-forward if you sart with the template in the TPSDK. If there are different non-netstandard dependencies that's another issue, it makes things harder. It would be great to get this over the line |
I've opened #314 with my attempt at this, I have some questions I'll post there. |
Suggest closing this in favor of #314 |
Implemented in #314 |
No description provided.