[Experimental] Compile against Microsoft.Data.SqlClient

[daniellittledev]

The aim is to replace all the namespaces to point to new types, get the solution to build, then the tests to pass.

See #374

[smoothdeveloper]

@daniellittledev the build script is using System.Data.SqlClient you may keep the reference in paket.dependencies and it should be able to run the build.

[daniellittledev]

@smoothdeveloper any tips on debugging a type provider, the initial namespace swap compiled but I was getting null reference exceptions in the tests project.

[smoothdeveloper]

@daniellittledev you need to setup the initial solution to run devenv.exe or attach the debugger to it.

You may adjust https://github.com/fsprojects/FSharp.Data.SqlClient/blob/dabf2cb456f9d592cfaf97818882cba8601a08dd/src/SqlClient/Properties/launchSettings.json through the project properties settings dialog under "Debug" to point at location of devenv.exe on your machine.

[daniellittledev]

I'm trying to find information on if Type providers, particularly the DesignTime project can target netcoreapps instead of netstandard. Because the configuration library loads as a reference assembly instead of an implementation at runtime.

[smoothdeveloper]

@daniellittledev the best I've gleaned on the area about what is going on with assembly loading in designer time, has been stepping through the TP SDK code, but it doesn't highlight how the IDE is first loading the designer assembly itself.

It could be that there are issues there to address, but getting to debug those means getting one more level in the stack (like debugging F# tooling for VS, or FCS for Ionide, or the FCS that ships with Rider).

I maybe misguided, but the amount of knowledge that is written, even in the TP SDK documentation wasn't conducive for me to identify issues actually occurring on the ground, where seemingly, the right assemblies are put in the right places.

One reason it didn't help is that the mechanism of loading the design assemblies is basically specific to each IDE and remains opaque, when I worked with Visual Studio, I could fare a bit farther IIRC with .net design time assembly (which can still be targetted with current TP SDK used in this repository, but not the most recent versions).

If you have issues to get into the debug stage of loading the assemblies, please let me know (gitter.im or fsharp.slack.com works for direct messages).

I'm sensibilized to the idea that, theoritically, just netstandard is the way to go.

None of what I say above is related to Microsoft.Data.SqlClient though, but when I looked at the netstandard design time target in the main branch.

The one first question is which IDE are you looking at in your current investigation?

[daniellittledev]

I've tried a few variations, note that I'm just trying to get anything working at the moment. I've spent quite a bit of time on this now and continue to run into issues:

• SqlClient (netstandard), DesignTime (dotnetapp)

In this configuration the Type Provider was unable to locate the DesignTime assembly when trying to load it. It appears that the lib and typeproviders directories must match.

• netstandard2.0
• typeproviders
  • fsharp41
    • netstandard2.0

I also looked at how the type (providers are loaded)[https://github.com/fsharp/fslang-design/blob/master/tooling/FST-1003-loading-type-provider-design-time-components.md] and asked a question about (what version type provider loading changed in)[https://github.com/dotnet/fsharp/pull/3864#issuecomment-812759178]

• SqlClient (dotnetapp), DesignTime (dotnetapp)

This didn't work either, I think the DesignTime assembly still failed to load.

• SqlClient (netstandard), DesignTime (netstandard)

This configuration does load the DesignTime assembly but fails to load other assemblies due to reference assemblies being loaded. Previously I had this problem with System.Configuration.ConfigurationManager but planned to remove it to see if I could move forward without it. However, I'm currently getting the same error for System.Runtime and I'm pretty sure I can't remove that.

why --group DesignTime System.Runtime
Paket version 5.257.0
NuGet System.Runtime - 4.3.1 is a direct (paket.dependencies) dependency.
It is part of following dependency chains:

-> Microsoft.Data.SqlClient - 2.1.2
  -> Microsoft.Identity.Client - 4.28.1
    -> System.ComponentModel.TypeConverter - 4.3
      -> System.Collections - 4.3
        -> System.Runtime - 4.3.1

-> System.Data.Common - 4.3
  -> System.Collections - 4.3
    -> System.Runtime - 4.3.1

The full error message I get when loading the TestProjects project is:

Error FS3033 The type provider 'FSharp.Data.SqlCommandProvider' reported an error: 
Could not load file or assembly 'file:///C:\Program Files\dotnet\sdk\NuGetFallbackFolder\microsoft.netcore.app\2.2.0\ref\netcoreapp2.2\System.Runtime.dll' or one of its dependencies. 
Reference assemblies should not be loaded for execution.  
They can only be loaded in the Reflection-only loader context. (Exception from HRESULT: 0x80131058)
SqlClient.Tests.NetCoreApp	C:\Projects\FSharp.Data.SqlClient\src\SqlClient.TestProjects\SqlClient.Tests.NetCoreApp\Program.fs	18

I think I've run out of ideas and I'm not sure why it's loading the reference assembly. I can't find any more information on reference assemblies or how to avoid loading them when writing a type provider.

@smoothdeveloper I'm using Visual Studio 2019

[smoothdeveloper]

@daniellittledev thanks for the detailed account of your journey (and putting issues), so even without System.Data.SqlClient but the newer bits under Microsoft.Data.SqlClient, the type of issues boil down to be similar as to binding the assemblies in the IDE process.

Given you are using vs2019, this process ends up binding to a dotnet framework runtime, it would be worth checking if it is possible to create a VS extension (which is also loaded in process) that loads the same assemblies (or binds to those actually shipping with VS) to see if the problem happens even lower in the stack (with no F# TP SDK nor F# VS Editor bits in the way) but this way out of scope of consuming the TP SDK.

I'm not sure what is the wiggling room in between dotnet (framework or core) runtime and the TP SDK as to try to hack around the loading of assemblies in the context of the type providers, this, similarly as above, requires spending time in the whole F# tooling stack and troubleshooting assembly binding issues.

On a world of hope, I've seen C#/VB roslyn tooling is starting to migrate out of process, and I gather the same will happen with F# tooling in time, this would allow to debug stuff without the heaviness of VS debugging.

Previously I had this problem with System.Configuration.ConfigurationManager but planned to remove it to see if I could move forward without it.

I faced similar issue, and this should actually prompt us, instead of ifdefing our way around, to look at just that issue, this would stop us in our track even before involving Microsoft.Data.SqlClient.

I'm currently not having at mind, actions to undertake for troubleshooting, but narrowing it down (a smaller TP using the same TP SDK bits as this repository at first) and pushing upstream to the compiler repository would probably be first aim.

[daniellittledev]

@smoothdeveloper This could be part of my problem fsprojects/FSharp.TypeProviders.SDK#371

[smoothdeveloper]

@daniellittledev understood, if there are hurdles in progressing with having target dependent binaries, I'll try to help. Thanks for keeping track of this issue.

Maybe if some code needs to be different depending the target framework of the runtime assemblies, you can add new #if directives in your branch.

I don't know what specific things we need to do with msbuild files on top of that.