.NET Standard - issues referencing library that uses SQLProvider

[MaciekFlis]

Description

I have a project that successfully talks to DB, but the same function fails when referenced from another project.

Repro steps

1. Clone https://github.com/MaciekTheFinalForm/sqlIssueMinimalExample
2. dotnet run on DataAccessApp project
3. dotnet run on ActualApp project

Alternative repro steps

1. Create a function that some retrieves data from Db
2. Call that function in the project
3. Call that function in another project

Expected behavior

Both executions succeed

Actual behavior

Only first execution succeeeds. The second fails with

Unhandled Exception: System.IO.FileNotFoundException: Could not load file or assembly 'FSharp.Data.SqlProvider, Version=1.1.42.0, Culture=neutral, PublicKeyToken=null'. The system cannot find the file specified.

Related information

• Postgres
• Operating system: Windows 10
• Branch: v1.1.42
• dotnet --version is 2.1.4

[Thorium]

To use type provider with .NET Standard you have to use compatible fsharp compiler and do the compilation with .Net451 version of SQLProvider.dll. On runtime you can use the .NET Standard dll.

[MaciekFlis]

It is working on runtime, just not when called from another assembly. How can I fix it?

[Thorium]

Ok, the first issue is that your ActualApp .NET FSharp.Data.SqlProvider.dll seems to end-up being version net451 and not version netstandard2.0 so the .NET Standard cannot use it on runtime.

Just add a copy or reference to the file so that there will be the netstandard2.0 version of the file in the ActualApp bin folder. It can be done in multiple ways, e.g. adding to your ActualApp project file from NuGet cache or from any other local folder:

  <ItemGroup>
    <Reference Include="FSharp.Data.SqlProvider">
      <HintPath>C:\Users\myuser\.nuget\packages\SQLProvider\1.1.42\lib\netstandard2.0\FSharp.Data.SqlProvider.dll</HintPath>
    </Reference>
  </ItemGroup>

Now, it seems that the dotnet.exe doesn't clean up the resources nicely when you try to rebuild. So please delete bin and obj folders under ActualApp before any build attempts.

What will fail next is that ActualApp doesn't find Npgsql.dll and System.Threading.Tasks.Extensions.dll as they are checked from the .\libs in the build of ActualApp also. So either create a folder libs under the ActualApp and copy the two dlls also there, or just create a path that will work for both projects.

[MaciekFlis]

That did help, thanks a lot!

Just to be sure: when you said

On runtime you can use the .NET Standard dll

you actually meant

On runtime you need to use the .NET Standard dll

?

[Thorium]

It depends on .NET Standard backward compatibility, but I think the current short answer is yes. :-)