-
Notifications
You must be signed in to change notification settings - Fork 281
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
"System.Data.SqlClient is not supported on this platform" on .NET 6 on RHEL and AlmaLinux, works fine on .NET 5 and under Ubuntu #1643
Comments
@alex-jitbit this seems like duplication of #1390 and some other similar issues when using Kerberos authentication on Unix. Please check that issue thread. |
@JRahnama nope, not using Kerberos auth, simply MS SQL user with password. This is a library/targeting/dependency issue, strictly |
What is your Publish command? |
@ErikEJ it's Once again, the same build works fine on Ubuntu, Windows Server etc. But some linux distros throw this error. |
The System version of the library can only be updated as part of the runtime. The last runtime it shipped with was netcore 3.1. So regardless of the bug status I don't think it's going to get fixed in the System version. Can you try with the Microsoft version of the library from this repo and see if it reproduces? |
@alex-jitbit I will look into this, but as a wild guess could this be related/similar to #1249 and #81? |
@JRahnama nope, I'm not using docker, it's a standalone SQL Server installation, accessed over network. And a standalone aspnetcore app (also - not in docker) |
@Wraith2 just tried with Microsoft.Data.SqlClient ! SAME ERROR !
|
The exception is trivially reproducible on WSL2: just install NET5 works fine. NET6 also works fine, but only on Ubuntu, not RHEL or its forks |
Have you tried using the latest SDK? |
I would try it with the latest .NET 6 servicing release first. |
Yes 6.0.105 is not the latest SDK |
Latest is 6.0.301 I think - but it can be confusing |
I have just installed the latest aspnetcore 6.0.6 runtime, which is the latest servicing release, and have the same exact error. It really feels like you guys are just dragging the issue. Meanwhile almost a dozen of our customers are waiting for a fix. P.S. do I really need the SDK installed to run apps though? Isn't the runtime enough? I spent an hour trying to find a way to install the "latest SDK" on RHEL/Alma/etc, and MS website does not describe any info. If you really want me to - please provide the instructions. https://docs.microsoft.com/en-us/dotnet/core/install/linux-rhel - is not very helpful. |
I'm building a WM with nested virtualization enabled so I can setup all the stuff needed for wsl2 debugging. If it was a simple fix I wouldn't need to do that. So yes I imagine you're right that we're all dragging this out but it's because it's not a trivial thing to setup debugging for. |
@Wraith2 appreciate |
The source of the problem in the current code is SqlClient/src/Microsoft.Data.SqlClient/src/Microsoft/Data/SqlClient/TdsParserStaticMethods.cs Lines 24 to 31 in d8fcede
notice the comment and lack of try block. |
Overall the lib is behaving as if it's running on windows, which is odd. have you tried a more mainstream liux? |
Looks to me like it should be using the newer OperatingSystem class to guard against the call to the registry (which does not exist in linux unless running on wine). I am surprised it does not throw on all unix OS’s. |
If I guard that error I hit an error in SNIInitialize when it can't load the sni.dll file. That means that it's trying to use the windows implementation. The nuget restore shouldn't be be choosing that implementation. So it isn't that we're doing anything wrong in code at runtime only that the wrong implementation was chosen. I don't know exactly where that choice is made, or how. Cross platform isn't an area that I'm well versed in. |
perhaps the issue is that they are not publishing it as FDD dependent but as rid specific as well (by using Also I think having them skip the apphost as well to force usage of |
There's no deployment step at all. Both through wsl debugging and directly using dotnet run it uses the windows assembly. It shouldn't. |
That is odd. |
Any news regarding this issue? SqlClient is currently unusable on Linux. |
It is usable under some Linux, just not the specific one that you want to use. We need to know why the nuget restore process isn't identifying your distro as Linux and that isn't something that is part of this library. You may need to open an issue on nuget and get their help. |
I'm getting this issue with PopOS 22 ( which is based on ubuntu I believe ). I specify the RID and it still appears. All my other code works fine except for this SqlClient package. |
I have the same issue after updating to the latest version of PopOS 22.04:
Microsoft.Data.SqlClient is the latest version 5.0.0. Here's my SDK and runtime versions:
|
I got it working by doing the following (based on steps from here: dotnet/core#7699)
Package: *
This will install a newer SDK version (6.0.400 [/usr/share/dotnet/sdk]) which apparently solves this problem. |
@alex-jitbit does the provided solution work for you? |
@JRahnama I will run my tests and get back to you. |
I believe the issue may be related to missing RIDs, such as for Rocky Linux, in the runtime. I've opened PR dotnet/runtime#74164 for Rocky Linux on the 6.0 servicing line. |
I noticed that if I build .NET 6 project referencing |
@Alex-Sob the part that the assembly is loaded from bin/runtimes is expected. |
@JRahnama Yes, but my question is - does that make sense that after build bin folder contains stub assembly that contains only code throwing |
@Alex-Sob Because the stub assembly is the fallback in case the .NET runtime's RID inference logic fails, i.e. it doesn't find any specific runtime implementation of the assembly at hand. In the current state of things, there is a gap in .NET 6.0 in the sense that Rocky Linux (and I assume Alma as well) are not supported by the runtime identifier detection logic. Effectively, depending on the platform, the .NET runtime may not be able to infer the OS to be either win-x64 or linux-x64 (which are the two implementations provided by In other words, the gap is in the .NET runtime RID inference logic, not in SqlClient itself. I suspect other libraries which have the same stub+specific implementation structure will have the same problem. I've submitted a PR to fill in the gap for Rocky Linux, but it probably needs to be done for other distributions such as Alma as well. |
P.S. This mechanism is in fact what enables applications to be distributed while targeting several runtime platforms. You can of course override the RID during publishing (e.g. linux-x64), but in that case, the application will only run on that specific platform. |
Anyone solved this on Pop!_OS 22.04? EDIT: Solved installing the dotnet SDK manually and setting the path manually on Rider.
|
So I've been working on this problem for a little bit and here is what I've encountered
Example **Step 3 introduced a new bug/problem. I was able to get the application to startup and run but noticed that several of my EF Core queries stopped returning data. Even though the logged query should have returned something. **[EDIT] Upon further inspection my PC is set to EST and the date was suppose to be UTC and it made a conversion which is why the query returned different reuslts. This is likely my bug. Step 3 is the winner
|
Apparently this problem is affected by the value of RuntimeInformation.RuntimeIdentifier I went to /etc/os-release and changed ID from "nobara" to "fedora", which also changed RuntimeInformation.RuntimeIdentifier from "nobara.36-x64" to "fedora.36-x64" and everything worked again, so I guess it may be possible to fiddle with some of the values in this (or similar) file on other systems to make them fit into supported whitelist. I understand this can probably be dangerous and is not something anyone should normally do but maybe this information can be helpful to some people. I tried looking into possibility of temporarily changing these values just to run dotnet and apparently on systems with lsb_release like Ubuntu it is possible to set path to os info with LSB_ETC_LSB_RELEASE variable but I don't see anything of the sort for Fedora/Red Hat. You can install lsb_release on Fedora but idk if this would change anything. |
closing this as it's not an issue with the Microsoft.Data.SqlClient client package. |
I was able to bypass this issue by putting all of EFCore (and Microsoft.Data.SqlClient) into generic linux-* rids and then manually installing them via extraction from tar.gz files into the Also doing such bypass as an experiment also allowed me to be able to roll forward new updates to efcore to the discord bot without needing to rebuild which for me is a bonus because of servicing releases being considered critical for me (also the fact that rebuilding can be a nightmare). |
I managed to get it running using this workaround. |
Does anyone have a link to another bug report? I'm not sure I understand the problem correctly, and I can't find out where to go to follow up on this issue. |
Yes I do But still facing the same Issue |
@alex-jitbit can you still reproduce this on RHEL 8 (not Alma)? Do you have a complete project I can copy and run? My understanding is that this is an issue in how a source-built .NET (that is, the version included in Linux distro repositories, not the Microsoft-built .NET) can have a broken Runtime Identifer (RID) graph, or a bug in how the RID itself is computed. That results in .NET being unable to navigate the RID graph to go from "This is distro $foo" (eg, the RID This is also why something like To see if your .NET runtime is affected by the bug, compare the For example, on RHEL 8, the RID values look consistent and appear in the RID fallback graph in the
Compare that with
|
With @omajid suggestion, I was able to change the Microsoft.NETCore.App.deps.json so I can use SQLClient without having to install the binary version and playing around with paths Extract the archive and go to ./shared/Microsoft.NETCore.App/6.x.x/Microsoft.NETCore.App.deps.json Go to your deps.json file on your OS, which in /usr/lib/dotnet/shared/Microsoft.NETCore.App/6.x.x/Microsoft.NETCore.App.deps.json Be aware that this is not 100% sure SQLClient will working probably after this. |
Throwing in my 2 cents I set the target runtime as linux-x64 and the Deployment mode as "Self-Contained" |
This is my Visual Studio publish profile it works also I agree that does not work in other situations.
|
works for me, thanks |
Describe the bug
We have a cross platform ASP.NET 6.0 app (published as "portable") that runs fine on Windows, Ubuntu etc, but throws the above error on RHEL and AlmaLinux. Reverting to the older version of the app that targets .NET 5 works fine.
Both versions
System.Data.SqlClient 4.8.3
andMicrosoft.Data.SqlClient
throw this error. My connection-string uses an SQL user with a password, not using Kerberos or windows-integrated authentication.To reproduce
Create a .NET Core 6.0 app that references SqlClient, publish, deploy to RHEL, run with
dotnet MyProject.dll
THIS IS TRIVIALLY REPRODUCABLE on AlmaLinux 8 under WSL2 (available in MS Store). But it works fine under Ubuntu under WSL2.
Install WSL2, install Almalinux 8 from MS Store, run
sudo yum install dotnet-sdk-6.0 -y
to install dotnet, then run the app usingdotnet MyProject.dll
Almalinux dotnet--info output:
The text was updated successfully, but these errors were encountered: