Strong name validation failed. (Exception from HRESULT: 0x8013141A) Unable to compile

[TonyHenrique]

I am new at F#, wondered by so many good things, but also stuck with some problems I can not figure out how to proceed.

I am trying to use the SQLProvider, but this error occurs:

Error	FS3033	The type provider 'FSharp.Data.Sql.SqlTypeProvider' reported an error: Unable to resolve assemblies. One of MySql.Data.dll, MySqlConnector.dll (e.g. from Nuget package MySql.Data) must exist in the paths: 
 C:\temp\fsConsoleApp2\fsConsoleApp2
C:\Users\tonyv\.nuget\packages\mysql.data\6.10.5\lib\netcoreapp2.0
C:\Users\tonyv\.nuget\packages\sqlprovider\1.1.23\lib\netstandard2.0
C:\WINDOWS\system32 
Details: 
Strong name validation failed. (Exception from HRESULT: 0x8013141A)

I checked and the DLL are on the correct folder. I also specified a f folder, containing the MySqlConnector.dll and MySql.Data.dll, but it does not compile.

[Thorium]

If you are using .Net core app 2, try removing MySQL.Data package and using only MySqlConnector.

[TonyHenrique]

I tried this (removing MySQL.Data package and using only MySqlConnector.),
but did not work here.

Then I created a new F# Console Application (.Net 4.7.1),
put the files on the resolution folder:

• FSharp.Data.SqlProvider.dll
• MySql.Data.dll
• MySql.Data.xml
• MySqlConnector.dll

and now SQLProvider Works !

[svdHero]

Any progress on this? I've just created an F# .NET Core 3.1 console application and get exactly the same error. Please re-open this issue.

What is the solution to this? Can't we use SQLProvider with .NET Core, yet?

[Thorium]

@svdHero what database? If MySql/MariaDb, are you using MySqlConnector?
Do you have the files in the resolution path?

You can use .NET Core, however I don't know the latest status: Typeproviders did use compile-time .NET framework libararies and runtime .NET Core libraries. I assume that is still true.

[svdHero]

@Thorium thanks for your reply.

My project file looks like this:

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>netcoreapp3.1</TargetFramework>
  </PropertyGroup>

  <ItemGroup>
    <Compile Include="Common.fs" />
    ...
  </ItemGroup>

  <ItemGroup>
    <PackageReference Include="MySql.Data" Version="8.0.19" />
    <PackageReference Include="SQLProvider" Version="1.1.76" />
    <PackageReference Include="Suave" Version="2.5.6" />
  </ItemGroup>

</Project>

The compiler error I get is this:

Severity	Code	Description	Project	File	Line	Suppression State
Error	FS3033	The type provider 'FSharp.Data.Sql.SqlTypeProvider' reported an error: Unable to resolve assemblies. One of MySql.Data.dll, MySqlConnector.dll (e.g. from Nuget package MySql.Data) must exist in the paths: 
 W:\GIT_WORKSPACES\VisualStudio_WS\RPE\RPE_BackEnd\projects\BT.RPE.BackEnd.WebServiceApp
C:\Users\XXX\.nuget\packages\mysql.data\8.0.19\lib\netstandard2.1
C:\Users\XXX\.nuget\packages\sqlprovider\1.1.76\lib\netstandard2.0
C:\Program Files (x86)\Microsoft Visual Studio\2019\Professional\Common7\IDE 
Details: 
Strong name validation failed. (Exception from HRESULT: 0x8013141A)	BT.RPE.BackEnd.WebServiceApp	W:\GIT_WORKSPACES\VisualStudio_WS\RPE\RPE_BackEnd\projects\BT.RPE.BackEnd.WebServiceApp\CompositionRoot.fs	30	Active

However, the directory C:\Users\XXX\.nuget\packages\mysql.data\8.0.19\lib\netstandard2.1 does contain the file MySql.Data.dll.

I am using Visual Studio 2019 for compiling the project/solution.
Am I doing anything wrong? I am new to both F# and the whole .NET Core stuff.

[svdHero]

Ah, I just discovered
https://fsprojects.github.io/SQLProvider/core/netstandard.html#MySql
Sorry, so it's still MySqlConnector only? I assumed that was old information from 2017 and eventually MySql.Data would be supported under .NET Core, too.

My fault. I will go and try it with the Connector.

[svdHero]

@Thorium I still get the exact same error message, although I replaced MySql.Data by MySqlConnector and did a

    [<Literal>]
    let resolutionPath = @"C:\Users\XXX\.nuget\packages\mysqlconnector\0.61.0\lib\netstandard2.1"

    [<Literal>]
    let developmentConnectionString = "Server=localhost;Database=Foo;Uid=Bar;Pwd=Umu;SslMode=Required;AutoEnlist=false;ConvertZeroDatetime=true;"


    [<Literal>]
    let dbVendor = Common.DatabaseProviderTypes.MYSQL

    type sql = SqlDataProvider<
        ResolutionPath = resolutionPath,
        ConnectionString = developmentConnectionString,
        DatabaseVendor = dbVendor
        >

However, since the compiler error does not mention

C:\Users\XXX\.nuget\packages\mysqlconnector\0.61.0\lib\netstandard2.1

, but still

C:\Users\XXX\.nuget\packages\mysql.data\8.0.19\lib\netstandard2.1

seems weird. Is the compiler still expecting MySql.Data?

[Thorium]

Currently the reflection needs all the reference assemblies to be present in one path. So I recommend putting the dlls to a folder under your solution and not trying to use nuget cache location directly.

[svdHero]

I would certainly prefer that. That's always been the case with C# in Visual Studio 2013.
Could you tell me how to do that? I've only moved to VS 2019 (and F#) last week.

Is that something I can do the project or solution file? I am using nuget from inside VS, not paket.

[svdHero]

Exectuing

dotnet nuget locals all -c

solved the original problem and the compiler did pick up MySqlConnector.dll now.

However, now I get the following error:

Severity	Code	Description	Project	File	Line	Suppression State
Error	FS3033	The type provider 'FSharp.Data.Sql.SqlTypeProvider' reported an error: Unable to load one or more of the requested types. Retrieve the LoaderExceptions property for more information.
Details: 
Could not load type 'System.ICloneable' from assembly 'System.Runtime, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'.
Could not load type 'System.Data.Common.DbCommandBuilder' from assembly 'System.Data.Common, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'.
Could not load type 'System.Data.Common.DbDataAdapter' from assembly 'System.Data.Common, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'.
Could not load type 'System.Data.Common.RowUpdatingEventArgs' from assembly 'System.Data.Common, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'.
Could not load type 'System.Data.Common.RowUpdatedEventArgs' from assembly 'System.Data.Common, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'.
Could not load file or assembly 'System.Runtime.Extensions, Version=4.2.1.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. Das System kann die angegebene Datei nicht finden.
Could not load file or assembly 'System.Net.Primitives, Version=4.1.1.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. Das System kann die angegebene Datei nicht finden.
Could not load type 'System.ReadOnlyMemory`1' from assembly 'System.Runtime, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'.
Could not load type 'System.IO.Stream' from assembly 'System.Runtime, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'.
Could not load type 'System.ReadOnlySpan`1' from assembly 'System.Runtime, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'.
Could not load file or assembly 'System.Memory, Version=4.2.0.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51' or one of its dependencies. Das System kann die angegebene Datei nicht finden.
Could not load file or assembly 'System.Transactions.Local, Version=4.0.1.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51' or one of its dependencies. Das System kann die angegebene Datei nicht finden.
Could not load type 'System.Runtime.CompilerServices.IAsyncStateMachine' from assembly 'System.Runtime, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'.
Could not load type 'System.Memory`1' from assembly 'System.Runtime, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'.	BT.RPE.BackEnd.WebServiceApp	W:\GIT_WORKSPACES\VisualStudio_WS\RPE\RPE_BackEnd\projects\BT.RPE.BackEnd.WebServiceApp\CompositionRoot.fs	30	Active

@theimowski , is this related to what you said about reflection? What I don't understand is, how this is in line to the official nuget principle from 2017, stating

Solution-local packages folders are no longer used – Packages are now resolved against the user’s cache at %userdata%.nuget, rather than a solution specific packages folder. This makes PackageReference perform faster and consume less disk space by using a shared folder of packages on your workstation.

Rethinking, I'd rather stick with this principle. Is that a no-go for SQLProvider then?

And when you say "all the reference assemblies to be present in one path" what exactly does that mean? Do all DLL files have to be in a single folder?

[Thorium]

Currently, yes, in a single folder... There is definitely the issue here, as the .NET reflection needs all the referenced assemblies to be near to work, and there is no way to load the assemblies from the Nuget-cache at the time of the reflection loading. At least I don't know a way, so if there is, I would happy if someone would let me know how.

[svdHero]

So in a nusthell, SQLProvider cannot be used according to the best practice way NuGet is supposed be used. That's a shame. 😞

[Thorium]

Right. Any ideas on this (or PRs) accepted. :-)

Currently SQLProvider probes a few folders of given path, but won't search through the user's whole hard disk. And also another problem is that the NuGet cache path has dlls for all different frameworks. Now, SQLProvider should then know somehow which dll to load per runtime used (may vary on compiletime vs runtime). Doesn't sound very error-prone.

[Thorium]

We've been also thinking if SQLProvider could be multiple different Nuget-packages with hard-coded dependencies, instead of reflection. Like SQLProvider.MySql that would reference the correct libraries directly. Maybe still have the current database-independent solution there as the base-package. This would need some project-packaging refactoring.

The initial idea with the existing solution is, that often people are tied to some specific version of the drivers anyway, now they can dynamically select whatever version they like by just having those libraries in resolutionPath folder.