-
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
[Experimental] Compile against Microsoft.Data.SqlClient #375
base: master
Are you sure you want to change the base?
[Experimental] Compile against Microsoft.Data.SqlClient #375
Conversation
@daniellittledev the build script is using |
@smoothdeveloper any tips on debugging a type provider, the initial namespace swap compiled but I was getting null reference exceptions in the tests project. |
@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. |
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. |
@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 The one first question is which IDE are you looking at in your current investigation? |
089df23
to
9feb156
Compare
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:
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.
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]
This didn't work either, I think the DesignTime assembly still failed to load.
This configuration does load the DesignTime assembly but fails to load other assemblies due to
The full error message I get when loading the
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 |
@daniellittledev thanks for the detailed account of your journey (and putting issues), so even without 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.
I faced similar issue, and this should actually prompt us, instead of 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. |
@smoothdeveloper This could be part of my problem fsprojects/FSharp.TypeProviders.SDK#371 |
@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 I don't know what specific things we need to do with msbuild files on top of that. |
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