Dependency hell

How to resolve “Microsoft.Data.SqlClient is not supported on this platform.” in an Azure Function App?

This post was most recently updated on March 18th, 2023.

3 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.”

  1. 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…

  2. 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:

  3. 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 downgrading Microsoft.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.

  4. 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.

  5. 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:
    SkipFunctionsDeps in the csproj file

    This was the one that fixed the issue for me!

  6. 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

mm
4.5 2 votes
Article Rating
Subscribe
Notify of
guest

3 Comments
most voted
newest oldest
Inline Feedbacks
View all comments