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" />

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.

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.

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.

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.

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.

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

Change the framework to .NetCore 3.x or .NetFramework 4.x...