System.Data.SqlClient throwing System.PlatformNotSupportedException when loaded via reflection

[softeering]

System.Data.SqlClient does not work when loading the external library (.NET Standard DLL) at runtime through reflection except if the library has been published for a specific platform (rid).
Trying to execute a SQL query against a SQL Server instance throws "System.PlatformNotSupportedException: System.Data.SqlClient is not supported on this platform" exception.

Repro steps and Visual studio solution can be found here:
https://github.com/softeering/NETStandardSQLClientRepro

I'm pretty sure this can be explained but I don't get why it doesn't work

[leedavi]

I have a the same error runing a different code set. The erorr is thown on the SqlConnection action.

[danmoseley]

The SqlClient package contains a "default" implementation for OS other than Unix/Windows which as you found throws an exception indicating it is dummy - does not work.

What are you trying to achieve? Can you load the Windows or Unix one instead?

[danmoseley]

https://github.com/dotnet/corefx/blob/master/src/System.Data.SqlClient/src/System.Data.SqlClient.csproj#L9

[softeering]

I'm trying to load a .NET Standard external assembly (one I wrote) via reflection. This assembly depends on System.Data.SqlClient but when I try to open a SqlConnection, the exception above is thrown.

FYI:

• The OS is Windows and not a "dummy" one
• Executing the code works if my .NET Standard assembly is referenced in the .NET Core console app (instead of using reflection)

As a reminder, deeper explanation, repro steps and Visual studio solution can be found here:
https://github.com/softeering/NETStandardSQLClientRepro

[danmoseley]

Thank you for the repro. I see the no-rid publish gives

NETStandardSQLClientRepro\ConsoleApp1\output\ClassLibrary1.Implementation.dll
NETStandardSQLClientRepro\ConsoleApp1\output\System.Data.SqlClient.dll
NETStandardSQLClientRepro\ConsoleApp1\output\runtimes\unix\lib\netstandard2.0\System.Data.SqlClient.dll
NETStandardSQLClientRepro\ConsoleApp1\output\runtimes\win\lib\netstandard2.0\System.Data.SqlClient.dll

The SqlClient next to your app is of course the throwing one. So your question is how to load and execute code in ClassLibrary1.Implementation.dll in such a way that it knows to load runtimes\win\lib\netstandard2.0\System.Data.SqlClient.dll instead of the System.Data.SqlClient.dll right next to it.

@weshaggard can you answer that? I am not famliar yet with .NET Core loader.

[softeering]

Yes it seems to be the issue.
The wrong System.Data.SqlClient.dll gets loaded when ClassLibrary1.Implementation.dll is loaded via reflection from the Console app (and works when ClassLibrary1.Implementation.dll is directly referenced in the console app)

[softeering]

FYI, if you delete the System.Data.SqlClient.dll under the root folder, the console app is not able to automatically load the one under the "runtimes" folder. You then get this error:

System.IO.FileNotFoundException: 'Could not load file or assembly 'System.Data.SqlClient, Version=4.2.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'. The system cannot find the file specified.'

[weshaggard]

Is there a reason you are creating your own custom AssemblyLoaderContext? When you create your own context you are responsible for finding and loading the correct assembly yourself. In your case line https://github.com/softeering/NETStandardSQLClientRepro/blob/master/ConsoleApp1/ConsoleApp1/Program.cs#L51 is trying to load an assembly by the same name in the root folder so when you delete it that is why it fails.

If you want the runtime to do the work for you then you will need to reference System.Data.SqlClient package from the application project so that it ends up in the deps file and thus will give the correct information to the loader of which one to load. Otherwise the custom AssemblyLoadContext is the one responsible for finding the correct version to load.

So depending on your scenario I would suggest you reference System.Data.SqlClient from your application and just call AssemblyLoadContext.Default.LoadFromAssembyPath to dynamically load your class library.

[leedavi]

In my case I'm trying to create a DB provider, for an application, so it can use multiple databases.

And I am using:

var myAssembly = AssemblyLoadContext.Default.LoadFromAssemblyPath();

However I have a 3 level architecture and I do call this from the 2nd level, the 3rd level being the actual provider which calls the connection method from System.Data.Client. So your explanation of the wrong context makes sense.

I only have test code, to try out my ideas in .Net Core. But I'll move it up to GitHub so everyone can see it.

I'll try the assembly load in the provider, to see if I can get it to work.

[leedavi]

I'm using this code to initialize the provider...

    public override void Connect(string XmlConfig)
    {
        var nbi = new NBrightInfo();
        nbi.XmlString = XmlConfig;

        foreach (var nod in nbi.XMLDoc.XPathSelectElements("genxml/dependancy/*"))
        {
            AssemblyLoadContext.Default.LoadFromAssemblyPath(nod.Value);
        }            
        var myAssembly = AssemblyLoadContext.Default.LoadFromAssemblyPath(nbi.GetXmlProperty("genxml/provider/assembly"));

        var myType = myAssembly.GetType(nbi.GetXmlProperty("genxml/provider/namespaceclass"));
        _objProvider = (IDataBaseInterface)Activator.CreateInstance(myType);
        _objProvider.Connect(XmlConfig);
    }

This works well with the DBreeze database, but he SQL connect fails.

The question is, I seem to be loading the provider and dependencies into the same "Default" context?

So why is it not taking the correct assembly?

Obviously adding a ref to SQL Client in the creation/calling application, defeats the idea of having a provider structure. But is this the reason it fails?

To me this seems a normal thing to do when creating a provider for SQL. So I would have expected this to work.

I'm not familiar with .Net Core so I'm happy to take any advice anyone has.

[softeering]

@weshaggard you're right, reason was simply a test for me. It didn't work with the default loader so I tried creating my own. I now understand where the problem could be.
I'll work to improve the loader in order to read other deps files and potentially visit the folder to find the right assembly since adding a reference to it is not a solution for me.

Thanks for the insight

[weshaggard]

If you cannot or do not want to have the application reference these packages then you will need to include a deps (or a deps like file) with your provider that you are loading dynamically and use that information in your custom AssemblyLoadContext to load the correct assembly. The default AssemblyLoadContext will only be able to able to find and load assemblies that are in the applications deps file.

[karelz]

The question seems to be answered, can we close the issue? (closing proactively)
Or is there some remaining question still open? (feel free to reopen / comment in such case)

[softeering]

@karelz More or less answered yes.
Would be great if you can direct me to some examples on how to use the DependencyContextJsonReader class to then load dependencies at runtime based on the platform the code is running on

Thanks