This post was most recently updated on July 26th, 2024.
4 min read.Hah – another interesting one. This article describes how to resolve an error along the lines of “Microsoft.Data.SqlClient: Microsoft.Data.SqlClient is not supported on this platform.“, thrown by the Azure Functions host. Apparently, you can run into this issue either on your local development machine or even in Azure.
Problem
For me, this error popped up after some house cleaning tasks – dependency updates, merging feature branches… You know the stuff. And suddenly, while the Azure Function App would build and run just fine, my SQL calls started failing.
The code I had was something like this:
try
{
var config = new ConfigurationBuilder()
.SetBasePath(context.FunctionAppDirectory)
.AddJsonFile("local.settings.json", optional: true, reloadOnChange: true)
.AddEnvironmentVariables()
.Build();
string connectionString = config["ConnectionStrings:ReadWriteConnection"];
var optionsBuilder = new DbContextOptionsBuilder<ReadWriteApplicationDbContext>();
optionsBuilder.UseSqlServer(connectionString);
using (var appdb = new ReadWriteApplicationDbContext(optionsBuilder.Options))
{
_ = await appdb.Database.ExecuteSqlRawAsync("SELECT 1");
}
}
catch (Exception e)
{
return new ExceptionResult(e, true);
}
And running it locally failed every single time with an error along the lines of “Microsoft.Data.SqlClient: Microsoft.Data.SqlClient is not supported on this platform.“.
Reason
I’m not going to dig into the details, but essentially, you’re in dependency hell. Let’s try and get you out of there as quickly as possible!
Solution
There are plenty of different reasons that could cause this – I went through a few steps outlined in different GitHub issues, but none of them helped. What they did, though, was to point me in the right direction!
The solutions below start from the simple and “normal” and advance onto… well, interesting, I suppose. I went with the last one, even though it’s not perfect – but it was the one that helped!
Time needed: 15 minutes
How to fix error “Microsoft.Data.SqlClient is not supported on this platform.”
- Downgrade your .NET or dependency version
You might not want to do this – however, if you’ve upgraded to .NET Core 3.x unintentionally, it might be a viable option for you to downgrade to .NET Core 2.2.x.
Or if you’ve just recently updated to something more modern, try downgrading and see if that helps.
Clean & build, and see if it helps!
Actually, there are plenty of ways you could fix your project by tweaking the versions of your Azure Functions SDK or .NET Core runtime – or even your dependencies!
And that brings us to the next option… - Downgrading isn’t feasible? Make sure you’re on the latest version!
There seem to be quite a few cases, where simply updating your .NET Core, Microsoft.NET.Sdk.Functions, AND any other dependencies that might internally reference Microsoft.Data.SqlClient (such as Entity Framework Core!)
In case upgrading everything simply doesn’t help and there’s no obvious downgrade option, you can also: - Set your “Microsoft.NET.Sdk.Functions” dependency to a specific version
If you’re using .NET Core 3.x but your SDK version is <3.0.3, go ahead and upgrade it to 3.0.3 or newer!
And this same guidance applies to newer versions of .NET as well – upgrade your .NET SDK.
Some users describe downgradingMicrosoft.NET.Sdk.Functions
from 3.0.3 (or newer) to 3.0.2 helps, too. And if you’re on 4.x branch, trying to downgrade might still be helpful.
Clean & build (and maybe even nuke all temp & artifact folders) and see if it helps!
A lot of users report 3.0.7 to be functional. Fiddling with the versions didn’t help me, though. - Move your Database Context Creation to Startup.cs if it’s somewhere else
Visual Studio might mess up including the right dependencies for your function if you’re only creating the DbContext somewhere else than Startup. Try instead configuring your context in the Startup.cs using SqlConnectionStringBuilder and see if it helps!
… or if you want to be a sly dog, keep your implementation as it is, and just add this to Startup.cs:var sb = new SqlConnectionStringBuilder();
var cs = sb.ConnectionString;
I was still out of luck with all this. - Skip copying your function.deps file
Okay – so this one is probably the least kosher one. Perhaps your function.deps.json file is getting misconstructed and causing the conflict, which will finally fail to load the required dependency.
Long story short, add this to your function .csproj file’s <PropertyGroup /> :<SkipFunctionsDepsCopy>true</SkipFunctionsDepsCopy>
Like shown below:
This was the one that fixed the issue for me! - New! Remove “SkipFunctionsDepsCopy” node from your .csproj -file
Haha, this is great! After a way newer update to Microsoft.NET.Sdk.Functions, I started getting the same error again.
Funnily enough, this time it was fixed by removing the <SkipFunctionsDepsCopy /> node from my .csproj -file altogether!
Just clean and build, and you should be good!
That’s all I had for today. Well – “today” as in a couple of separate days a year in between. Because this tech keeps moving, so dev environments keep breaking.
Anyway – let me know whether it helped or not! :)
References
- https://github.com/Azure/azure-functions-host/issues/5950
- https://github.com/dotnet/SqlClient/wiki/Frequently-Asked-Questions#11-why-do-i-get-a-platformnotsupported-exception-when-my-application-hits-a-sqlclient-method
- https://github.com/Azure/Azure-Functions/issues/1370
- How to fix PowerToys FancyZones in Windows 11? - September 24, 2024
- How to export the whole SSL (or TLS) certificate chain based on the original using PowerShell? - September 17, 2024
- How to solve keyboard shortcuts not working in Google Chrome on Windows? - September 10, 2024