dotnet / SqlClient

Microsoft.Data.SqlClient provides database connectivity to SQL Server for .NET applications.
MIT License
853 stars 286 forks source link

Strings.PlatformNotSupported_DataSqlClient is thrown when running on Manjaro #1631

Closed massaynus closed 1 year ago

massaynus commented 2 years ago

Is there an existing issue for this?

Describe the bug

I have a backend API made with asp.net core that relies on EF Core 6 and MSSQL for the data layer. the API and the migration commands run fine on both Windows and Ubuntu/Debian. When the same code and commands are used on Manjaro/Arch they fail with the following output:

$ dotnet ef database update
Build started...
Build succeeded.
info: Microsoft.EntityFrameworkCore.Infrastructure[10403]
      Entity Framework Core 6.0.2 initialized 'ApplicationDbContext' using provider 'Microsoft.EntityFrameworkCore.SqlServer:6.0.2' with options: MaxPoolSize=1024 
System.PlatformNotSupportedException: Strings.PlatformNotSupported_DataSqlClient
   at Microsoft.Data.SqlClient.SqlConnection..ctor(String connectionString)
   at Microsoft.EntityFrameworkCore.SqlServer.Storage.Internal.SqlServerConnection.CreateDbConnection()
   at Microsoft.EntityFrameworkCore.Storage.RelationalConnection.get_DbConnection()
   at Microsoft.EntityFrameworkCore.Storage.RelationalConnection.Open(Boolean errorsExpected)
   at Microsoft.EntityFrameworkCore.SqlServer.Storage.Internal.SqlServerDatabaseCreator.<>c__DisplayClass18_0.<Exists>b__0(DateTime giveUp)
   at Microsoft.EntityFrameworkCore.ExecutionStrategyExtensions.<>c__DisplayClass12_0`2.<Execute>b__0(DbContext c, TState s)
   at Microsoft.EntityFrameworkCore.SqlServer.Storage.Internal.SqlServerExecutionStrategy.Execute[TState,TResult](TState state, Func`3 operation, Func`3 verifySucceeded)
   at Microsoft.EntityFrameworkCore.ExecutionStrategyExtensions.Execute[TState,TResult](IExecutionStrategy strategy, TState state, Func`2 operation, Func`2 verifySucceeded)
   at Microsoft.EntityFrameworkCore.SqlServer.Storage.Internal.SqlServerDatabaseCreator.Exists(Boolean retryOnNotExists)
   at Microsoft.EntityFrameworkCore.SqlServer.Storage.Internal.SqlServerDatabaseCreator.Exists()
   at Microsoft.EntityFrameworkCore.Migrations.HistoryRepository.Exists()
   at Microsoft.EntityFrameworkCore.Migrations.Internal.Migrator.Migrate(String targetMigration)
   at Microsoft.EntityFrameworkCore.Design.Internal.MigrationsOperations.UpdateDatabase(String targetMigration, String connectionString, String contextType)
   at Microsoft.EntityFrameworkCore.Design.OperationExecutor.UpdateDatabaseImpl(String targetMigration, String connectionString, String contextType)
   at Microsoft.EntityFrameworkCore.Design.OperationExecutor.UpdateDatabase.<>c__DisplayClass0_0.<.ctor>b__0()
   at Microsoft.EntityFrameworkCore.Design.OperationExecutor.OperationBase.Execute(Action action)
Strings.PlatformNotSupported_DataSqlClient

Expected Behavior

It should run fine across all platforms as it used to do in .NET 5!

Steps To Reproduce

The code repo

Exceptions (if any)

System.PlatformNotSupportedException

.NET Version

6.0.102

Anything else?

$ dotnet --info
.NET SDK (reflecting any global.json):
 Version:   6.0.102
 Commit:    49861cb924

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

Host (useful for support):
  Version: 6.0.2
  Commit:  839cdfb0ec

.NET SDKs installed:
  6.0.102 [/usr/share/dotnet/sdk]

.NET runtimes installed:
  Microsoft.AspNetCore.App 6.0.2 [/usr/share/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 6.0.2 [/usr/share/dotnet/shared/Microsoft.NETCore.App]

To install additional .NET runtimes or SDKs:
  https://aka.ms/dotnet-download
$ uname -a
Linux massaynus-hp 5.15.41-1-MANJARO dotnet/aspnetcore#1 SMP PREEMPT Wed May 18 09:20:01 UTC 2022 x86_64 GNU/Linux
$ lsb_release -a
LSB Version:    n/a
Distributor ID: ManjaroLinux
Description:    Manjaro Linux
Release:    21.2.6
Codename:   Qonos
version: "3"

services:
  mssql:
    image: mcr.microsoft.com/mssql/server:2017-latest

    environment:
      - ACCEPT_EULA=Y
      - SA_PASSWORD=${MSSQL_SA_PASSWORD}
    ports:
      - 127.0.0.1:1433:1433
    volumes:
      - /var/opt/mssql:/var/opt/mssql
davidfowl commented 2 years ago

This should be moved to https://github.com/dotnet/SqlClient

cc @ajcvickers

massaynus commented 2 years ago

UPDATE! when I build the same code using the --os and --arch flags it works normally.

dotnet run --arch x64 --os linux

JamesChe91 commented 2 years ago

Hello, the flags works, thank you very much :bow: , but and for debug, how is it?

massaynus commented 2 years ago

as mentioned in the docs you can add a -c|--configuration <CONFIGURATION> flag to specify that

for example: dotnet run --arch x64 --os linux --configuration Debug

Although by default the project is ran in Debug mode

JamesChe91 commented 2 years ago

I'm sorry, I don't make myself understand. I was referring to debuging step by step in vscode at Linux. I get the same error and I'm trying to add the args in the launch.json file, but didn't work

JamesChe91 commented 2 years ago

I already have the answer. In the Task.json file add the args image

And in the launch.json file add linux-x64 to the program path image

AraHaan commented 2 years ago

Also consider updating sql server 2017 to 2019 (it comes with some improvements) and I would wait until 2022 become downloadable without a login to get that one too.

luizgambali commented 2 years ago

I was having a similar issue using PopOs, my app was running normally on Windows, but on Linux I got this message when I ran . After much searching, I found a solution that solved my problem on a Google forum (https://groups.google.com/g/exceldna/c/4PQLjPj76N4/m/w-0kVCYVDAAJ).

I added the following instructions in my csproj:

<Target Name="PostBuild" AfterTargets="PostBuildEvent">
     <Exec Command="cp $(OutDir)runtimes/unix/lib/netcoreapp3.1/Microsoft.Data.SqlClient.dll $(OutDir)" />
   </Target>

And it worked! I am using .net 6, entity framework 6.0.9

luanmm commented 1 year ago

Thank you for this solution, @luizgambali. This points towards a definitive solution, which is something that I would expect from Microsoft collaborators.

Regarding this error, everything I have seen is everybody closing issues without any solution or any clue, except from the community. And this kind of thing disappoints a lot.

The entire ecosystem that we are talking here is "proprietary" somehow: SQL Server is a Microsoft product and not a community project. And if we can't get help from the product collaborators/maintainers, I really don't have any motivation to keep using SQL Server without some kind of external requirement.

Here are the issues related to this very same problem (sorry for being repetitive, but this has been ignored for months):

https://github.com/dotnet/SqlClient/issues/1423 https://github.com/dotnet/SqlClient/issues/1427 https://github.com/dotnet/SqlClient/issues/1811 [...and so many others, even on "efcore" and "runtime" repositories, just search for "PlatformNotSupported"...]

I really don't see the WHY most of this issues are being closed, because they are not solved in any way. There is even issues where people changed the database from SQL Server to Sqlite and it is marked as "solved". So should I really change the database system because in SQL Server this error is supposed to occur? [Irony, of course.]

AraHaan commented 1 year ago

I agree, and since sql server is technically free, I actually wonder why Microsoft did not open source it yet.

jinek commented 1 year ago

I like the speed how issues get closed at SqlClient side.

jinek commented 1 year ago

@massaynus Don't we want to have at least described workaround? Don't we want to have a fix of this issue in the future?

massaynus commented 1 year ago

@jinek I would love for everybody to have a clear solution

as of currently there seems to be a build issue, since all I needed is to hint the architecture I'm targeting to get things fixed!

UPDATE! when I build the same code using the --os and --arch flags it works normally.

dotnet run --arch x64 --os linux

Also this solution from @luizgambali hints at the same issue, it seems to be a build problem at the end of the day, maybe the linux archs are not picked up properly or not all of them are supported.

Currently we have seen the problem on both a debian based distro (PopOS) and an Arch based distro (Manjaro), but Ubuntu, CentOS, Debian would work just fine.

I was having a similar issue using PopOs, my app was running normally on Windows, but on Linux I got this message when I ran . After much searching, I found a solution that solved my problem on a Google forum (https://groups.google.com/g/exceldna/c/4PQLjPj76N4/m/w-0kVCYVDAAJ).

I added the following instructions in my csproj:

<Target Name="PostBuild" AfterTargets="PostBuildEvent">
     <Exec Command="cp $(OutDir)runtimes/unix/lib/netcoreapp3.1/Microsoft.Data.SqlClient.dll $(OutDir)" />
   </Target>

And it worked! I am using .net 6, entity framework 6.0.9

At the end of the day not all distoros are officially supported 🤔 Docs

Maybe the real issue is how to properly support linux? 😂

jinek commented 1 year ago

@massaynus Thank you for re-opening. I'm not sure whether I did something on my system or no, but now, after installing dotnet 7 and removing 6, it started to work.

massaynus commented 1 year ago

@jinek I haven't tried .NET 7 yet on my arch system, and it's not on hand currently so I cannot confirm if the issue is resolved 😓

jinek commented 1 year ago

Maybe the real issue is how to properly support linux? joy

Yep, I believe that is natural intention not to depend on OS title/id. However, I did not investigate so much as you guys, i had to drop this issue. Still, may be makes sense to keep issue open at least by the moment we confirm it's fixed with dotnet 7.

That fix dotnet run --arch x64 --os linux is just not clear for everybody how to run, some folks even have no clue of possible outcomes. And this one <Exec Command="cp $(OutDir)runtimes/unix/lib/netcoreapp3.1/Microsoft.Data.SqlClient.dll $(OutDir)" /> looks like would break incremental build. Sometimes that's not viable or not desired.

lcheunglci commented 1 year ago

Closing this issue as it's a .NET Runtime platform detection issue.