FSharp.Data.SqlClient
FSharp.Data.SqlClient copied to clipboard
designer assembly 'FSharp.Data.SqlClient.DesignTime.dll' cannot be loaded or doesn't exist
Description
Attempting to compile with latest 2.0.1 release
Repro steps
Following code does not compile
open FSharp.Data
[<Literal>]
let connectionString = @"redacted"
type userProfileDb = SqlProgrammabilityProvider<connectionString>
Expected behavior
Type provider gives access to stored procs
Actual behavior
Compiler error
SC : error FS3031: The type provider 'C:\Users\richa\.nuget\packages\fsharp.data.sqlclient\2.0.1\lib\netstandard2.0\FSharp.Data.SqlClient.dll' reported an error: Assembly attribute 'TypeProviderAssemblyAttribute' refers to a designer assembly 'FSharp.Data.SqlClient.DesignTime.dll' which cannot be loaded or doesn't exist. Could not load file or assembly 'file:///C:\Users\richa\.nuget\packages\fsharp.data.sqlclient\2.0.1\lib\netstandard2.0\FSharp.Data.SqlClient.DesignTime.dll' or one of its dependencies. The system cannot find the file specified. [C:\repos\AuthenticationServer\src\Sse.Retail.AuthServer.Web\Sse.Retail.AuthServer.Web.fsproj]
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
- Operating system Windows 10
- Branch
- Database versions and sample databases being used
- .NET Runtime, CoreCLR or Mono Version Core 2.1.403
- Editing Tools (e.g. Visual Studio Version) VsCode with Ionide
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.
# find . -name 'FSharp.Data.SqlClient.DesignTime.dll'
./packages/fsharp.data.sqlclient/2.0.1/lib/typeproviders/fsharp41/net40/FSharp.Data.SqlClient.DesignTime.dll
./packages/fsharp.data.sqlclient/2.0.1/lib/typeproviders/fsharp41/net461/FSharp.Data.SqlClient.DesignTime.dll
./packages/fsharp.data.sqlclient/2.0.1/lib/net40/FSharp.Data.SqlClient.DesignTime.dll
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:
# find . -name 'FSharp.Data.DesignTime.dll'
./packages/fsharp.data/3.0.0/lib/netstandard2.0/FSharp.Data.DesignTime.dll
./packages/fsharp.data/3.0.0/lib/net45/FSharp.Data.DesignTime.dll
./packages/fsharp.data/3.0.0/typeproviders/fsharp41/netstandard2.0/FSharp.Data.DesignTime.dll
./packages/fsharp.data/3.0.0/typeproviders/fsharp41/net45/FSharp.Data.DesignTime.dll
@richardjharding What version of Visual Studio do you have installed? Are you following all of the guidance here? https://github.com/Microsoft/visualfsharp/issues/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 (Microsoft.SqlServer.TransactSql.ScriptDom
and Microsoft.SqlServer.Types
) which require full framework.
not using Visual Studio - vs code with Ionide - have followed the guidance at Microsoft/visualfsharp#3303 ie by adding the fsc.props project import but still get that error
@richardjharding But what version do you have installed? fsc.props
is setting the path to the F# compiler, trying to find out which version it is using.
The design-time component depends on a couple of libraries (Microsoft.SqlServer.TransactSql.ScriptDom and Microsoft.SqlServer.Types) which require full framework.
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 Microsoft.SqlServer
dependencies in a netcore version of the DTC. If that worked, it would a) eliminate the Mono requirement on MacOS/Linux and b) eliminate the need for https://github.com/Microsoft/visualfsharp/issues/3303 workarounds in projects referencing the TP.
@vasily-kirichenko A few weeks ago I did send an email to the maintainer of those Microsoft.SqlServer
nuget packages, asking about the possibility of a netstandard version. Have not heard anything.
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 dotnet build
produces the error.
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
dotnet new console -lang f#
dotnet add package FSharp.Data.SqlClient
dotnet build
already spews out that error.
Performing ^^^ commands, I have build error having VS, Rider and full framework on windows:
FSC : error FS3031: The type provider 'C:\Users\kirichenko.nuget\packages\fsharp.data.sqlclient\2.0.1\lib\netstandard2.0\FSharp.Data.SqlClient.dll' reported an error: Assembly attribute 'TypeProviderAssemblyAttribute' refers to a designer assembly 'FSharp.Data.SqlClient.DesignTime.dll' which cannot be loaded or doesn't exist. Could not load file or assembly 'C:\Users\kirichenko.nuget\packages\fsharp.data.sqlclient\2.0.1\lib\netstandard2.0\FSharp.Data.SqlClient.DesignTime.dll'. The system cannot find the file specified. [C:\Users\kirichenko\kirichenko.fsproj] FSC : warning FS3005: Referenced assembly 'C:\Users\kirichenko.nuget\packages\fsharp.data.sqlclient\2.0.1\lib\netstandard2.0\FSharp.Data.SqlClient.dll' has assembly level attribute 'Microsoft.FSharp.Core.CompilerServices.TypeProviderAssemblyAttribute' but no public type provider classes were found [C:\Users\kirichenko\kirichenko.fsproj]
Does adding fsc.props
fix this problem?
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):
- The RTC (and its dependencies) must be available at runtime; they end up in your application's bin folder and get packaged with the app, etc. For FSharp.Data.SqlClient, the RTC is available for net40 and netstandard2.0 targets.
- The DTC is required to make the provided types available to your design-time tooling and to the compiler. In our case, the DTC has .Net Framework-only dependencies (
Microsoft.SqlServer.Types
andMicrosoft.SqlServer.TransactSql.ScriptDom
) and thus does not target netstandard2.0 - see discussion here, specifically bullet point 6. - This means that a Core application should work just fine at runtime on any machine with an appropriate Core runtime installed, but in order to compile, you will need:
- .Net Framework or Mono to be installed, and
- fsc.props to be imported (see https://github.com/Microsoft/visualfsharp/issues/3303)
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 Microsoft.SqlServer
libs - so it probably wouldn't be a huge lift to migrate them to netstandard. Unfortunately they aren't open source, so there's really nothing we can do other than whine about it.
https://github.com/fsprojects/FSharp.Data.SqlClient/pull/320
@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
Installing into projects:
- Creating model and downloading packages.
Could not detect any platforms from 'typeproviders' in 'C:\Users\richa\.nuget\packages\fsharp.data.sqlclient\2.0.1\lib\typeproviders\fsharp41\net40\FSharp.Data.SqlClient.DesignTime.dll', please tell the package authors
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 fsc.props
workaround?
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 Microsoft/visualfsharp#3303.
If you have an older version of VS 2017, (pre 15.3 I believe) you may simply need to update it.