-
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
designer assembly 'FSharp.Data.SqlClient.DesignTime.dll' cannot be loaded or doesn't exist #318
Comments
I tested it on a .net core project in Rider, everything worked. I don’t know if Ionide supports type providers on .net core. Could you try VS or Rider? |
So I think Ionide is not relevant here? - should just run at cmd line with dotnet build I think? |
@richardjharding BTH, I'm not using Core at all. @samhanes any ideas? |
This is reproducible on a Mac using .NET Core SDK 2.1.500 + VS Code + Ionide. I do not have mono installed as I'm trying to move to pure .NET Core tooling. You do not even have to try to use a stored procedure in order to get the error. Examining the nuget package cache, it can be confirmed that there is no design-time assembly generated in the netstandard2.0 folder.
|
afaik type providers must be hosted on .net 4.5+ framework at design time (at least this is what was required a half of year ago). @dsyme could you please confirm this? |
I think this is no longer the case. Works just fine in FSharp.Data providers for JSON, for example. DLL layout there:
|
@richardjharding What version of Visual Studio do you have installed? Are you following all of the guidance here? dotnet/fsharp#3303 @vjraitila Mono is required to run the design time component on MacOS - it has dependencies on full framework dlls. You should be fine at runtime with just netcore, however. @vasily-kirichenko I'm planning to submit a PR to add some of these things to the documentation - there are some gotchas that are not at all obvious. |
@samhanes So, the design-time component for FSharp.Data.SqlClient specifically has full framework dependencies - right? Just to clarify that this is obviously not a requirement for type providers in general. |
@vjraitila Yes that's right - this is a SqlClient-specific requirement. The design-time component depends on a couple of libraries ( |
not using Visual Studio - vs code with Ionide - have followed the guidance at dotnet/fsharp#3303 ie by adding the fsc.props project import but still get that error |
@richardjharding But what version do you have installed? |
I think these assemblies can be loaded by Core. |
@richardjharding The issue is that SqlClient uses a netfx-only DTC with a netstandard RTC - in order for that to work with a netcore project, I believe that you need to have VS 15.3 or above installed. Otherwise, the F# tooling is going to look for the DTC only in the same folder as the RTC which isn't going to work. Do I have that right @dsyme ? @vasily-kirichenko To be honest, I did not try loading the |
@vasily-kirichenko A few weeks ago I did send an email to the maintainer of those Although as you say, it might "just work" already. |
@samhanes I sent an email to him too, a half of year ago :) no response |
FYI this error pops up even without any SqlClient specific code - just adding a reference to the package and |
Yup. It is not just a design-time problem in that sense. The project does not compile at all with pure .NET Core tooling. Running
already spews out that error. |
Performing ^^^ commands, I have build error having VS, Rider and full framework on windows:
|
Does adding |
Yes that works for some reason. Is there a different version bundled with .net core or what is going on here? |
@r1sc @vjraitila I really need to document this better, but the underlying issue is that FSharp.Data.SqlClient is not fully netstandard compliant. The TP is split into a design-time component (DTC) and a runtime component (RTC):
|
I just want to report that I'm in the process of updating a large VS2015 solution using the provider and it seems to work well, so I haven't seen a regression on that front. @samhanes thanks a lot for the outstanding contribution, with your efforts the codebase got a nice cleanup along the upgrade. |
@samhanes Gotcha, thanks. I can confirm that instructing the SDK to explicitly use mono as a compiler in fsc.props does work around this issue. I just had to adjust some paths in order to make it work. Now if the maintainer of those Microsoft.SqlServer packages would just release netstandard2.0 builds for them... For what it's worth, I did send a message for them as well. |
@vjraitila Glad the workaround is working for you. I can't imagine there is any missing API surface in Core required by those |
@richardjharding Can this be closed? |
I was still getting the same issue - I created a new console app 2.1.403 sdk and now I get an error when paket attempts to install the package
not sure if this is a related issue? - am I using an unsupported sdk combination? |
@richardjharding What version of Visual Studio 2017 do you have installed? Are you using the |
using the fsc.props workaround - have other type providers working fine with that, not using visual studio - just vscode, dotnet cmd line |
@richardjharding I understand you are using the dotnet cli, but the workaround still requires a .net framework or Mono F# compiler as described in dotnet/fsharp#3303. If you have an older version of VS 2017, (pre 15.3 I believe) you may simply need to update it. |
ah ok I understand - I'll check version of compiler and update - do you know where I can find out for sure what the min version should be for this type provider? |
Based on the info in the issue linked above, I believe it is 15.3 but I have not verified that. |
I'm also seeing this with CLI tools. I have tried the work-around, but it doesn't seem to help. To clarify, this is for an |
The workaround does the trick for me on Windows as well (and did on a Mac). Remember to import the Also examine the props file whether it can find the compiler at least in one of the locations it tries to look for it. After that I can successfully compile using Visual Studio and the command line. When it comes to VS Code + Ionide, there's yet another trick. If you have set the F# auto completion runtime to use .NET Core in the
I’ve only used NuGet up to this point, but Paket does give me the same error as you guys. I do not yet know if that is somehow related or not. |
@panesofglass To clarify, you are getting a compile-time error when you run |
@vjraitila I did not realize we have that issue with Ionide with Honestly, I think there's still a chance that we could make the DTC work on netstandard2.0 by referencing the net40 |
Well, as far as I can tell, referencing the However, I did find this package, which is available for netstandard2.0. Apparently this is the parser used by tools like SSMS. The API is different from the parser in |
@samhanes, yes, that is correct. I've added |
@samhanes, looks like I missed some projects. The exe project referenced two other libraries that also referenced the first library. Add |
Im running into issues with this as well. For me its split in 2. With a clean solution, VS Code and Ionide behaves properly with intellisenceand errors. Does anyone have a workaround or working solution for having both of these working at the same time? |
@projecteon does #318 (comment) help? The gist of the matter is to force the autocompletion component of VS Code + Ionide to use the same compiler as the dotnet CLI does. It currently ignores the setting in Although Sam did an excellent, and much needed job here by switching to the new type provider SDK, it unfortunately only got us half-way and still have to jump through quite a lot of hoops to make design-time work without a hitch when using the .NET Core SDK. AFAIK, the only way to properly fix the remaining issues requires either a significant refactoring effort or the Microsoft SQL Server team to provide netstandard ports of a couple of key libraries. In short, we can use SqlClient with .NET Core at runtime, but still need some flavor of full .NET Framework when developing and building. |
@vjraitila unfortunately that workaround did not work for me. Unless I'm missing something. I added this setting on workspace settings.json level. I'm still stuck clearing out obj/bin folders to get good intellisence in VSCode and Inoide after each build/dev build |
I have a the same error in VSCode + Ionide. |
Hello. This blog helps me to workaround this problem. https://medium.com/@dsincl12/f-with-net-core-2-0-4-and-sqlprovider-d8f071119da9 For fscToolPath I did't find the exactly but this works fine.
and for the last step i paste this piece
|
I ultimately gave up trying to get this to work, and just opened my project in Visual Studio 2017 (Community Ed.) and everything worked instantly. If you have the paket extension, then all you'll need is a solution file and away you go. |
Using the dotnet core 3.0 SDK and targeting
<PropertyGroup>
<FscToolPath>$(MSBuildThisFileDirectory)</FscToolPath>
<FscToolExe>fscfix.bat</FscToolExe>
</PropertyGroup>
|
Description
Attempting to compile with latest 2.0.1 release
Repro steps
Following code does not compile
Expected behavior
Type provider gives access to stored procs
Actual behavior
Compiler error
The file mentioned is not at that location - but wasn't sure if that was expected?
Have tried with and without the workaround with fsc.props file - again unsure from recent issues whether that workaround is required or not
Related information
The text was updated successfully, but these errors were encountered: