Reputation: 407
I'm using ASP.NET Core 2 with Entity Framework Core 2.0.2. I created a context and Add-Migrations
command in Package Manager Controller works fine.
However when Update-Database
command is used, I get an error:
System.Data.SqlClient is not supported on this platform
I can't figure out where the problem is. Can you help me? Thanks.
My .csproj
file:
<Project Sdk="Microsoft.NET.Sdk.Web">
<PropertyGroup>
<TargetFramework>netcoreapp2.0</TargetFramework>
<DebugType>portable</DebugType>
<PreserveCompilationContext>true</PreserveCompilationContext>
<DockerComposeProjectPath>..\docker-compose.dcproj</DockerComposeProjectPath>
</PropertyGroup>
<ItemGroup>
<Folder Include="wwwroot\" />
</ItemGroup>
<ItemGroup>
<PackageReference Include="Autofac.Extensions.DependencyInjection" Version="4.2.1" />
<PackageReference Include="Microsoft.AspNetCore.All" Version="2.0.6" />
<PackageReference Include="Microsoft.EntityFrameworkCore" Version="2.0.2" />
<PackageReference Include="Microsoft.EntityFrameworkCore.Design" Version="2.0.2" />
<PackageReference Include="Microsoft.EntityFrameworkCore.SqlServer" Version="2.0.2" />
<PackageReference Include="Microsoft.EntityFrameworkCore.Tools" Version="2.0.2" />
<PackageReference Include="Swashbuckle.AspNetCore" Version="2.3.0" />
</ItemGroup>
<ItemGroup>
<DotNetCliToolReference Include="Microsoft.VisualStudio.Web.CodeGeneration.Tools" Version="2.0.2" />
<DotNetCliToolReference Include="Microsoft.EntityFrameworkCore.Tools.DotNet" Version="2.0.2" />
</ItemGroup>
</Project>
Upvotes: 24
Views: 49342
Reputation: 23
In my case, I bumped the version from 4.4.0 to 4.9.0 in a .NET Core 3.1 project and got the same exception. Just downgrading the package to 4.8.6 solves my problem.
Upvotes: 0
Reputation: 39
I was able to resolve this issue by going into "Manage Nuget Packages" and updating the Microsoft.Data.SqlClient library to the latest version.
Upvotes: -1
Reputation: 68
I was in the exact same situation, add-migration
works fine, but update-database
get the "SqlClient Not wupported on this platform" error. I am using linux (Pop!_OS).
The accepted solution didn't work for me, so I tried a lot of alternatives.
The solution for me was to add <RuntimeIdentifier>linux-x64<RuntimeIdentifier>
to the .csproj of my WebApi. Just answering here in case other people still getting the same error.
Upvotes: 0
Reputation: 1008
For me, it got resolved by having the runtimes subdirectory available within the used bin directory (using .net 6.0 and Microsoft.EntityFrameworkCore.SqlServer Version="7.0.7" )
Upvotes: 0
Reputation: 5639
If you copy the dll from the unzipped nupkg package and got this error, make sure you use the right one with included dependencies like System.Runtime ... :
~/runtimes/unix or win/lib/netcoreapp2.1
for e.g. .net6.0
Upvotes: 0
Reputation: 1
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) Microsoft.Data.SqlClient is not supported on this platform."
go to manage nugget packages and do a downgrade. Hope it works for you
Upvotes: -1
Reputation: 39
I had this exact same issue with a .NET 5.0 console application i was deploying. I discovered that when i published the application the publish profiles target framework was set to 3.1 instead of 5.0 and that is what caused this error for me. After re-publishing with the correct target framework everything worked as expected.
Upvotes: 1
Reputation: 495
I spent a couple of hours on this but managed to resolve it. Posting here in case it helps someone else save some time.
In my .csproj files I had
<CopyLocalLockFileAssemblies>true</CopyLocalLockFileAssemblies>
Removing this solved my problem. Some information can be found here. Setting the value to true causes all dependencies to be copied to the output folder and for me, maybe when loading the application, it was getting confused about which System.Data.SqlClient.dll to load.
Upvotes: 2
Reputation: 51
Just in case somebody lands here who is trying to run System.Data.SqlClient on net50/netstandard on rid freebsd-x64: Microsoft.Data.SqlClient worked for me.
Maybe this works on every portable option and/or for all System.[...] ->Microsoft.[...] dll.
Upvotes: 3
Reputation: 940
Same problem here but for me it is a failure on the part of System.Data.SqlClient to load dynamically as part of a plugin. Our plugin dlls are loaded dynamically via Autofac and a controlling service selects the correct one at run time. Unfortunately System.Data.SqlClient will not load dynamically like this, result in the above error message. So I had to load it when the controlling service starts up. This is obviously not ideal but for now it is a usable workaround as all our plugins are still under our control.
I'll be more specific, following a question in comments.
A service selects plug-ins at run time. The plug-ins register their own dependencies via Autofac and if that dependency is a Nuget package they will also include the package as a normal Nuget dependency.
The controlling service registers the plug-in dlls on start up and the first time they are used the plug-in dependencies are also loaded. When System.Data.SqlClient load is attempted following a call to the plug-in that uses SqlClient the "not supported" error results.
Setting System.Data.SqlClient as a Nuget dependency in the controlling service works OK and the library is loaded correctly without error. However, this is not ideal because the the SqlClient library always has to be loaded by the controlling service even if the plug-in selected to run it does not need it.
In other words the SqlClient library is always loaded at service start up occupying resources, etc when it may not even be needed. But at least it works.
Upvotes: 15
Reputation: 533
I ran into this issue recently with .net standard 2.0 classes being consumed by a regular .net framework app. (.net 4.7.x). The only thing that ultimately fixed my issue was migrating from packages.config to PackageReference on the regular .net app.
Upvotes: 8
Reputation: 358
I ran into the same issue a couple of days ago - I'm not sure what the underlying issue is, but reverting some of the EntityFrameworkCore
nuget packages back to 2.0.0 seems to have resolved the issue for me. These are the packages I downgraded:
<PackageReference Include="Microsoft.EntityFrameworkCore" Version="2.0.0" />
<PackageReference Include="Microsoft.EntityFrameworkCore.Design" Version="2.0.0" />
<PackageReference Include="Microsoft.EntityFrameworkCore.SqlServer" Version="2.0.0" />
<PackageReference Include="Microsoft.EntityFrameworkCore.Tools" Version="2.0.0" />
Upvotes: 19