There is a System.Data.SqlClient nuget package
Azure Function - Microsoft.Data.SqlClient is not supported on this platform
Microsoft.Data.SqlClient is not supported on this platform. When using the portal to create Azure function in C#, System.Data.SqlClient doesnot have reference. So I tried Microsoft.Data.SqlClient. It compiled successfully, but while running, it throws the above exception.
How can I connect to the database using Azure portal in Function App
3 answers
Sort by: Most helpful
-
-
Robbinson Otunga 0 Reputation points
2023-02-17T11:08:34.17+00:00 @Ken Tucker True , I was using the Entitycore.sql and Core.tools most current version 7.2 , I downgraded the nuget package to 6.012 and it all worked well, When you get such error ,=> "
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
-
Russell Louks 0 Reputation points
2023-06-06T15:26:42.1133333+00:00 Preface: This solution may apply to the original issue if the faulting code is dynamically being loaded into the host process. If Azure functions are loaded through the clr_libhost, it's likely relevant.
In my case--and in several others out there apparently--the failing code using Microsoft.Data.SqlClient was loading into a native host process (as a managed plugin). On the same machine, the code works fine if the host exe is managed, but fails when loaded as a plugin with the "unsupported" error.
Looking at the load sequence in a debugger between the two scenarios provided a clue:
Standalone managed host (library load sequence) - Works
'SimpleClient.exe' (CoreCLR: clrhost): Loaded 'C:\temp\TestHost\SimpleHost\bin\Debug\net6.0\SimpleHost.dll'. Symbols loaded. 'SimpleClient.exe' (CoreCLR: clrhost): Loaded 'C:\temp\TestHost\SimpleHost\bin\Debug\net6.0\runtimes\win\lib\netcoreapp3.1\Microsoft.Data.SqlClient.dll'. 'SimpleClient.exe' (CoreCLR: clrhost): Loaded 'C:\Program Files\dotnet\shared\Microsoft.NETCore.App\6.0.16\System.Data.Common.dll'.
Native host (library load sequence) - Fails
'NativeSOETestHost.exe' (CoreCLR: clr_libhost): Loaded 'C:\temp\TestHost\TestPlugin\bin\Release\net6.0\SqlClientTest.dll'. Symbols loaded.` `'NativeSOETestHost.exe' (CoreCLR: clr_libhost): Loaded 'C:\temp\TestPlugin\plugin\bin\Release\net6.0\Microsoft.Data.SqlClient.dll'. `
Faults here when attempt is made to use types in Microsoft.Data.SqlClient.dll
Observe that dotnet uses a different loader to handle these two cases (clr_host vs clr_libhost), and that when clr_host is used, the implementation is apparently smart enough to dig into the generated runtimes subfolder to find the version of Microsoft.Data.SqlClient.dll that works (under netcoreapp3.1). Altering the plugin to use this version (manually copied/deployed) resolved the issue for us.