Orleans: OrleansSqlUtil missing System.Data.SqlClient

[amccool]

after upgrading Microsoft.Orleans.OrleansSqlUtils from 1.3.1 to 1.4.0 receive this error.

01:41:38Z [Runtime.Scheduler.WorkerPoolThread/3] Error XXXX.vshost.exe 0: [2017-03-01 01:41:38.120 GMT 24 ERROR 100646 MembershipOracle 172.18.4.160:11111] !!!!!!!!!! MembershipFailedToStart Exc level 0: System.InvalidOperationException: Unable to find and/or load a candidate assembly for 'System.Data.SqlClient' invariant name.

this error was resolved by nuget'ing in System.Data.SqlClient 4.3.0

Seems that the nuspec needs to include the dependency? Yes this is SqlServer, and I dont know what you want to do about MySql, Postgres, etc, dependencies

[veikkoeeva]

@amccool Orleans moved in 1.4.0 to be more .NET Core compatible and one of the changes in the framework involves the functionality and availability of DbProviderFactories (see https://github.com/dotnet/corefx/issues/4571).

Now the libraries need to be explic explicitly included in the search path, i.e. Orleans binaries directory. Before that running on .NET Full framework they were implicitly available with the framework and the factory knew how to probe the right paths (application binaries, GAC, the configuration from local config, machine config etc.). In the .NET Core scenario it might not make sense to assume one using ADO.NET would have a SQL Server backend or would want to include the libraries for that by default.

It was @galvesribeiro that did the actual port, so he might still remember the exact details. :)

[sergeybykov]

We could add a Microsoft.Orleans.OrleansSqlUtils.MSSQL package that would add SQL Server specific dependencies like System.Data.SqlClient. I'm not sure if it's worth it though.

[galvesribeiro]

I though about that... But those .MSSQL, .Postgres, .MySQL packages, would have nothing more than a reference to the underlying DB client package and maybe hold the .sql script to create the structure... Does it worth maintain a package just for it?

[sergeybykov]

Does it worth maintain a package just for it?

That's exactly what I'm not sure about. It's a bit of a burden. But if it would simplify life of a number of people that use those databases...maybe it is worth throwing a .nuspec for that.

[galvesribeiro]

I think having a mention in docs would be better...

[veikkoeeva]

I think having a mention in docs would be better...

This is the normal state of affairs to anyone else and has always been. It'd be confusing if all the sudden there were a different convention.

[sergeybykov]

Resolved via #2915.