"System.PlatformNotSupportedException: Microsoft.Data.SqlClient is not supported on this platform." on Linux

2.1k Views Asked by At

I just started getting this error today on my Linux system, building a net6 solution on Rider - It builds but won't run. I've tried upgrading my version of Microsoft.Data.SqlClient from nuget but that's made no difference. This was working fine last week.

There are a couple of things I've done that may have broken it - I got mono working over the weekend to try and get some legacy NETFramework code building for another project, for one. The other was a global update of ef tools dotnet tool update --global dotnet-ef as I had the 5.x tools version installed.

My OS has multiple runtimes installed...

dotnet --list-runtimes                                                                                                                                               
Microsoft.AspNetCore.App 6.0.0 [/usr/share/dotnet/shared/Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 6.0.13 [/usr/share/dotnet/shared/Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 7.0.2 [/usr/share/dotnet/shared/Microsoft.AspNetCore.App]
Microsoft.NETCore.App 6.0.0 [/usr/share/dotnet/shared/Microsoft.NETCore.App]
Microsoft.NETCore.App 6.0.13 [/usr/share/dotnet/shared/Microsoft.NETCore.App]
Microsoft.NETCore.App 7.0.2 [/usr/share/dotnet/shared/Microsoft.NETCore.App]

The app builds to target 6.0.

I'm a bit lost as to where to start trying to find problems - I#ve read about the netstandard2.0 version of this library being a kind of breaking stub, but the Assembly Explorer in Rider tells me that the version of Microsoft.Data.SqlClient in my bin directory is net6. I'm not sure what I should be seeing in the runtimes directory in here - I have a unix runtime shown there but NOT a linux specific runtime - Is this a red herring or am I on to something?

I've reverted the dotnet-ef tool by uninstalling it and running dotnet tool install --global dotnet-ef --version 5.0.0 - This hasn't helped at all.

4

There are 4 best solutions below

2
On BEST ANSWER

I recommend to not install dotnet from the arch or AUR repositories at all. Instead use the script provided by Microsoft. This installs the original builds.

https://learn.microsoft.com/en-us/dotnet/core/tools/dotnet-install-script

I created this wrapper script which I use any time I need to install a machine:

#!/bin/bash
# This script installs specified versions of .NET Core and the latest LTS

# Function to install a specific .NET Core version
install_dotnet_version() {
    local version="$1"
    echo "Installing .NET Core version $version..."
    curl --silent --show-error --location https://dot.net/v1/dotnet-install.sh \
        | sudo bash /dev/stdin -c "$version" --install-dir /usr/share/dotnet
}

# Install .NET Core versions
install_dotnet_version 3.1
install_dotnet_version LTS
install_dotnet_version 7.0

# Create a symlink to dotnet executable, if not present
if [ ! -f /usr/bin/dotnet ]; then
    sudo ln -sf /usr/share/dotnet/dotnet /usr/bin/dotnet
fi

1
On

Try typing "dotnet --info" in terminal. Then take your target OS and add it to your c# cs.proj files...

<RuntimeIdentifier>ubuntu.22.04-x64</RuntimeIdentifier>

For me. Works for me! The program is loading the wrong DLL, as there are multiple for different platforms. This way, your specifically tell c# which dll to load.

I don't know if this is the best solution. I have spent a few hours researching, and I tried this. It works for me. Previously I tried just using "Linux x64", but it didn't work. So try to be as specific as you can, and use dotnet --info

1
On

It seems that the issue was, in part, related to having 2 6.x framework versions installed, or with 6.0.13 - I'd tried installing the 6.x packages from the Manjaro repositories over the weekend to replace the script installs.

Dani's comment above pointed me in the right direction (https://github.com/dotnet/SqlClient/issues/1643#issuecomment-1265104713) - There's something odd going on here.

I removed them all and installed again using the .dotnet-install.sh script - that just did nothing, so I copied the 6.0.0 install from a backup folder (mv .old FTW) and it all fell into place again.

Whether this is an issue with 6.0.13 or with having multiples I'm not sure.

1
On

TLDR: I think this is a bug in the .NET builds of Manjaro Linux. When you downloaded Microsoft's builds of .NET, it didn't have this bug and worked correctly.


This is what the OS says about itself:

# cat /etc/os-release 
NAME="Manjaro Linux"
PRETTY_NAME="Manjaro Linux"
ID=manjaro
ID_LIKE=arch
BUILD_ID=rolling
ANSI_COLOR="32;1;24;144;200"
HOME_URL="https://manjaro.org/"
DOCUMENTATION_URL="https://wiki.manjaro.org/"
SUPPORT_URL="https://forum.manjaro.org/"
BUG_REPORT_URL="https://docs.manjaro.org/reporting-bugs/"
PRIVACY_POLICY_URL="https://manjaro.org/privacy-policy/"
LOGO=manjarolinux

And this is what .NET thinks about your OS:

sh-5.1# dotnet --info
.NET SDK (reflecting any global.json):
 Version:   6.0.113
 Commit:    4a23b50f97

Runtime Environment:
 OS Name:     manjaro
 OS Version:  
 OS Platform: Linux
 RID:         arch-x64
 Base Path:   /usr/share/dotnet/sdk/6.0.113/
...

Do you see how confused .NET is about whether this is Arch Linux or Manjaro?

.NET has a fallback graph that tells it which assets from another OS it can use:

# jq '.runtimes' /usr/share/dotnet/shared/Microsoft.NETCore.App/6.0.13/Microsoft.NETCore.App.deps.json
{ 
  "arch-x64": [
    "arch",
    "linux-x64",
    "linux",
    "unix-x64",
    "unix",
    "any",
    "base"
  ]
}              

But that only contains arch-x64 (that is, Arch Linux), not manjaro-x64.

If you try and build/run your application with the environment variable COREHOST_TRACE, you can see output like this:

HostRID is manjaro-x64
Falling back to base HostRID: linux-x64

So it finally decides this OS is Manjaro, but then has no idea that Manjaro is compatible with everything listed in the fallback graph above. It just falls back to Linux.

Unfortunately, Microsoft.Data.SqlClient is built for either Windows (windows) or for Unix (unix). .NET can't find a linux variant. It finally uses the fallback version of Microsoft.Data.SqlClient.dll, one that just prints errors instead of doing anything useful.