Microsoft.Data.SqlClient: Microsoft.Data.SqlClient is not supported on this platform.

[marc-wilson]

I am migrating from a functions 2.0 project to a 3.0 project. I followed the steps outlined here but am unable to run the project (fails at runtime)

Error:

Microsoft.Data.SqlClient: Microsoft.Data.SqlClient is not supported on this platform.

Here is my package dependencies:

    <PackageReference Include="CsvHelper" Version="12.1.2" />
    <PackageReference Include="Microsoft.Azure.Functions.Extensions" Version="1.0.0" />
    <PackageReference Include="Microsoft.Azure.WebJobs.Extensions.Storage" Version="3.0.10" />
    <PackageReference Include="Microsoft.NET.Sdk.Functions" Version="1.0.30-beta2" />
    <PackageReference Include="Octokit" Version="0.36.0" />

However, I suspect that this error is coming from my Database Project which is using Entity Framework 3.0. Here's those dependencies:

      <PackageReference Include="CsvHelper" Version="12.1.2" />
      <PackageReference Include="EFCore.BulkExtensions" Version="3.0.0" />
      <PackageReference Include="Microsoft.AspNetCore.Identity" Version="2.2.0" />
      <PackageReference Include="Microsoft.AspNetCore.Identity.EntityFrameworkCore" Version="3.0.0" />
      <PackageReference Include="Microsoft.EntityFrameworkCore" Version="3.0.0" />
      <PackageReference Include="Microsoft.EntityFrameworkCore.Design" Version="3.0.0" />
      <PackageReference Include="Microsoft.EntityFrameworkCore.SqlServer" Version="3.0.0" />

I am not explicitly pulling in Microsoft.Data.SqlClient anywhere within my project / solution. I did find the reference in the Entity Framework packages though, so I assume it's coming from that.

The only other thing worth mentioning here is that my Web App (running dotnet 3.0) is able to utilize the same database project without any issues.

dotnet --info

.NET Core SDK (reflecting any global.json):
 Version:   3.0.100
 Commit:    04339c3a26

Runtime Environment:
 OS Name:     Mac OS X
 OS Version:  10.15
 OS Platform: Darwin
 RID:         osx.10.15-x64
 Base Path:   /usr/local/share/dotnet/sdk/3.0.100/

Host (useful for support):
  Version: 3.0.0
  Commit:  95a0a61858

.NET Core SDKs installed:
  2.1.4 [/usr/local/share/dotnet/sdk]
  2.1.401 [/usr/local/share/dotnet/sdk]
  2.2.106 [/usr/local/share/dotnet/sdk]
  3.0.100 [/usr/local/share/dotnet/sdk]

.NET Core runtimes installed:
  Microsoft.AspNetCore.All 2.1.3 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.All 2.2.4 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.App 2.1.3 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 2.2.4 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 3.0.0 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 2.0.5 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.1.3 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.1.13 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.2.4 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App]
  Microsoft.NETCore.App 3.0.0 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App]

[brettsam]

@erick2red -- It looks like your problem is with System.Data.SqlClient, which is a different underlying issue than Microsoft.Data.SqlClient. We've been discussing both here, which is getting confusing (I originally merged issues here b/c both assemblies had the same initial root cause -- so that's my fault for the confusion).

However, it does look like we have a runtime issue here where we fixed this in v2 and the change did not make it to v3. Can you try a temporary workaround while we port the fix? Locally in your local.settings.json, add "FUNCTIONS_V2_COMPATIBILITY_MODE": "true". And add the same App Setting in Azure. That will allow you to load the version of the assembly that you're referencing and I think that should unblock you for now. If so, let me know, and I'll update this when we've deployed the fix.

@Robzilla is still having problems with Microsoft.Data.SqlClient -- so if anyone has a repro with that, I'll continue investigating.

[Robzilla]

Hi @brettsam, any feedback on the getting VS2019 Preview working with the new function templates? It's fairly easy to reproduce. Just install a clean copy of VS2019 preview, turn on the new templates and try to create a new project using the new function templates. I have posted all the Visual Studio version info previously.

[brettsam]

@Robzilla -- I just installed a fresh VS2019 Preview, selected "ASP.NET and web development", "Azure development", and ".NET Core cross-platform development" and everything works. What options did you select?

@soninaren -- It looks like there may be some combo of VS options that causes the error above. Can you loop in someone from VS to see if they know how that can happen?

[erick2red]

@brettsam

Can you try a temporary workaround while we port the fix? Locally in your local.settings.json, add "FUNCTIONS_V2_COMPATIBILITY_MODE": "true". And add the same App Setting in Azure. That will allow you to load the version of the assembly that you're referencing and I think that should unblock you for now. If so, let me know, and I'll update this when we've deployed the fix.

Yes, this made it work. Thanks!

[DrBarnabus]

Just got hit by this and FUNCTIONS_V2_COMPATIBILITY_MODE seems to have fixed it for the time being.

Is this thread going to be updated when the fix is released so I can remove this?

[bmeijwaard]

Getting the same, tried some suggested stuff in this thread. I did get Azure Function to work with SqlConnection targetting Microsoft.Data.SqlClient 1.1.0, but as soon as a also target EntityFrameworksCore it fails again, also after upgrading to function v3 and netcoreapp3.1. What is found is that EFCore is targetting Microsoft.Data.SqlClient v1.0.19269.1 as i found in some project.assets.json

"Microsoft.EntityFrameworkCore.SqlServer/3.1.0": {
        "type": "package",
        "dependencies": {
          "Microsoft.Data.SqlClient": "1.0.19269.1",
          "Microsoft.EntityFrameworkCore.Relational": "3.1.0"
        },
        "compile": {
          "lib/netstandard2.0/Microsoft.EntityFrameworkCore.SqlServer.dll": {}
        },
        "runtime": {
          "lib/netstandard2.0/Microsoft.EntityFrameworkCore.SqlServer.dll": {}
        }
      },

[Ponomareff]

The message is displayed if function.deps.json is missing in bin folder, either locally or in Azure.

The problem is caused by invalid expression in _FunctionsPostBuildDepsCopy target (in ...packages\microsoft.net.sdk.functions\3.0.1\build\Microsoft.NET.Sdk.Functions.Build.targets)

<Target Name="_FunctionsPostBuildDepsCopy" AfterTargets="PostBuildEvent" Condition="'$(SkipFunctionsDepsCopy)' != 'true'">
    <Copy SourceFiles="$(OutDir)$(ProjectName).deps.json" DestinationFiles="$(OutDir)bin\function.deps.json" Condition="Exists('$(OutDir)$(ProjectName).deps.json')"/>
  </Target>

It relies on $(ProjectName) which is not correct. It should be $(AssemblyName). You are not able to reproduce the issue on 'Hello World' application, because both MSBuild variables have the same value. Try to change assembly name to be different from Project name and put this line in your handler code

var parser = new SqlConnectionStringBuilder("Data Source=(localdb)\\MSSQLLocalDB;Initial Catalog=master;Integrated Security=True;Connect Timeout=30;Encrypt=False;");

Hope this covers some scenarios listed here, @brettsam

[brettsam]

Great catch @Ponomareff. @fabiocav -- FYI.

[Robzilla]

@Ponomareff can you share your proj file and any other relevant config. At the moment I have the SQL Client people, pointing the finger at the Azure Function people who then point the finger that the Visual Studio people. All the product teams have their simple examples working and say "job done, works on my machine". Unfortunately the real world doesn't work that way :(

[fabiocav]

All the product teams have their simple examples working and say "job done, works on my machine".

@Robzilla if you look at the interactions above, you'll see that isn't the case. It's unfortunate this is how you're perceiving this, but particularly in this area, fixes and improvements are validated based on known scenarios and what customers report, and those do become part of the validation suite.

@brettsam just merged a fix and we'll have that out ASAP, but if you can share the details of what is impacting you (i.e. share a repro for your case since you believe it isn't capture by what is currently validated against), we can ensure that addresses your problem as well. We'll update the issue as soon as the update is available so you can check if it helps you.

[brettsam]

I've just released to nuget Microsoft.Net.Sdk.Functions 1.0.31 (for v2 apps) and 3.0.2 (for v3 apps) that contain the fix from @Ponomareff above. For details on the releases see https://github.com/Azure/azure-functions-vs-build-sdk/releases.

There is still one known issue with System.Data.SqlClient (and possibly more?) that require a runtime update in production:

• For v2, there is no workaround other than targeting version 4.6 or earlier. But the fix is committed and the release should complete within a week. I will update back here when it is completed.
• For v3, you (interestingly enough...) set the FUNCTIONS_V2_COMPATIBILITY_MODE setting as detailed above. Side note -- this is because our v3 release was pushed out with newer bits than v2 -- and v2 doesn't actually have this fix yet. I will update back here when this flag is no longer needed.

If anyone has more scenarios, please let me know the details and I can dig in.

[Robzilla]

@fabiocav I tried to create a example repo with the latest version of Visual Studio using the latest project templates but this failed with an exception (https://github.com/Azure/Azure-Functions/issues/1370#issuecomment-562991756). So I couldn't even create a repo to share and nobody seems to be able to advise. I would have thought being able to create a new Azure functions project with up to date tools and templates should at least work out of the box. But it doesn't seem that way and I am getting silence from MS on this.

[brettsam]

@Robzilla -- I attempted to reproduce this and told you what I chose for my installation options here. The list you've provided can be helpful but I'm not sure how to reproduce that list given the Workload selection UX that the Installer provides. But since this is unrelated to the issue here and this is getting off track, I've created https://github.com/Azure/Azure-Functions/issues/1434 to narrow that down. Please hop over there and we can try to figure out the issue, looping in the VS experts if we need them.

[bmeijwaard]

Just updated Functions SDK to 3.0.2. Still got (Microsoft.Data.SqlClient is not supported on this platform.) Also set "FUNCTIONS_V2_COMPATIBILITY_MODE": "true" in local.settings.json

Currently running on netcoreapp3.1 and functions v3 .NET Core SDK Version: 3.1.100 VS2019 Version 16.4.1 Azure Functions Core Tools (3.0.1975) Function Runtime Version: 3.0.12930.0

For futher investigation I could provide my entire repo.

[fabiocav]

@bmeijwaard if you could share a repository with a repro, that would indeed help.

[bmeijwaard]

@bmeijwaard if you could share a repository with a repro, that would indeed help.

Is there a way to send you the 'zipped' code in private, since it is a private repo? Edit: sent you an email with the repo.

After looking into it a little deeper I suspect that the issue is coming from Microsoft.AspNetCore.Identity.EntityFrameworkCore in https://github.com/aspnet/AspNetCore/blob/master/eng/Versions.props line 264 version 1.0.19249.1 of Microsoft.Data.SqlClient is referenced. In one of my project depedencies I have referenced Microsoft.AspNetCore.Identity.EntityFrameworkCore v3.1.0 using IdentityDbContext class.

[brettsam]

@bmeijwaard -- If you want to contact me via email (my microsoft mail is in my github profile), we can work through it that way, then come back here with any findings. We likely don't need your code -- just the project structure with project files.

[bmeijwaard]

Awesome, ill forward the mail I sent to Fabio.

[Ponomareff]

@bmeijwaard Before you struggle with reproduction steps, please verify the following for your project: function.deps.json and runtimes are both present in bin folder. Same for your deployed Azure Function:

[bmeijwaard]

@Ponomareff this is the bin folder of the project. and runtimes

[ghost]

I just updated a function to .NET Core 3.1 today and had this exact same issue, which I was able to resolve based on this post. I added the setting "FUNCTIONS_V2_COMPATIBILITY_MODE": "true" to the local.settings and the server function and I updated my project file to copy the function.deps.json and that resolved the issue. Up until I did that, it worked fine locally but generated the error "Microsoft.Data.SqlClient is not supported on this platform." on the server

My .csProj file looks like this:

[Eirenarch]

Hit the System.Data.SqlCLient version of the problem today with the 3.0 (non-preview) release. The FUNCTIONS_V2_COMPATIBILITY_MODE did fix it but I am still wondering if I will ever be able to remove it after an update

[Robzilla]

@brettsam well I did get this running locally but failed on the server even after upgrading to the latest libs. See proj file below. I can confirm there is no function.deps.json file in the bin dir on the server as per https://github.com/Azure/Azure-Functions/issues/1370#issuecomment-565450516

I am currently publishing using VS2019 preview (latest patch as of 15th Dec 2019). I will be using a DevOps pipeline once I get the manual process working.

Hope that narrows it down. Any chance this is fixed in version 3.0.3?

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFramework>netcoreapp3.1</TargetFramework>
    <AzureFunctionsVersion>v3</AzureFunctionsVersion>
    <AssemblyName>TestDb.Functions</AssemblyName>
    <RootNamespace>TestDb.Functions</RootNamespace>
  </PropertyGroup>
  <ItemGroup>
    <PackageReference Include="Microsoft.Azure.Cosmos.Table" Version="1.0.6" />
    <PackageReference Include="Microsoft.Data.SqlClient" Version="1.1.0" />
    <PackageReference Include="Microsoft.NET.Sdk.Functions" Version="3.0.2" />
  </ItemGroup>
  <ItemGroup>
    <None Update="host.json">
      <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
    </None>
    <None Update="local.settings.json">
      <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
      <CopyToPublishDirectory>Never</CopyToPublishDirectory>
    </None>
  </ItemGroup>
</Project>

[soninaren]

@Robzilla if you are seeing the function.deps.json in the bin folder locally, but are not seeing the same on the server. Then i would recommend using the Run from Package file for deployment. The out logs from VS should show where the package (zip file) was generated locally. The contents of the function app on the server should match exactly with the contents of the zip file. Hope this helps.

[Robzilla]

@soninaren and @brettsam I am publishing to an existing app service plan via the zip deploy method in Visual Studio 2019 Preview. I am also creating a debug build and have set Delete Existing Files to true.

I have checked the zip file that is produced during the publish and function.deps.json is not there.

[fabiocav]

@Robzilla just wanted to give you an update. Things are a bit slower as some folks are out of the office for the holidays, but I'm blocking some time to look at the repro you've provided this week. Will provide an update as soon as we have more information.

If the deps file is not in the deployment payload, that would definitely explain why you're running into the problem, but would require a bit more investigation.

[Robzilla]

@fabiocav just let me know what debug you require from Visual Studio.

[fabiocav]

@Robzilla we have just made an SDK fix to address the issue you're seeing. We'll have that deployed at the beginning of the year, but we could make it available to you on a private feed before then, if you believe that would be helpful

@bmeijwaard thank you again for providing a repro for this, as the issue was triggered by a specific setup you have with your solution (shared more information over email). We have identified an issue here and will have the fix for this rolling out at the beginning of the year as well.

/cc @brettsam

[eastmane]

I seem to have hit a similar issue (I think) to @bmeijwaard - using EF Core, VS 16.4.2, and functions runtime 3.0.12930.0 - I get "Microsoft.Data.SqlClient is not supported on this platform" with or without FUNCTIONS_V2_COMPATIBILITY_MODE. I'm referencing Microsoft.Data.SqlClient 1.1.0 everywhere I can find it and the functions.deps.json and runtimes folder are present in bin.

I noticed that the file size on the Microsoft.Data.SqlClient in the bin folder is different to the filesize in my .nuget and the runtimes version (323KB in bin vs 1241KB in .nuget, despite same versions in properties) - inspired by https://stackoverflow.com/a/53952815/908 I included this in .csproj:

  <!-- For publish -->
  <ItemGroup>
    <None Include="$(USERPROFILE)\.nuget\packages\microsoft.data.sqlclient\1.1.0\runtimes\win\lib\netcoreapp2.1\Microsoft.Data.SqlClient.dll">
      <CopyToOutputDirectory>Always</CopyToOutputDirectory>
    </None>
  </ItemGroup>
  <!-- For local debug -->
  <Target Name="CopyToBin" BeforeTargets="Build">
    <Copy SourceFiles="$(USERPROFILE)\.nuget\packages\microsoft.data.sqlclient\1.1.0\runtimes\win\lib\netcoreapp2.1\Microsoft.Data.SqlClient.dll" DestinationFolder="$(OutputPath)\bin" />
  </Target>

This copies the .nuget version into bin and it seems to work fine.

Any ideas what's going on here and why I'm getting a seemingly incompatible dll included by default?

Happy to share projects etc if it'd help.

[fabiocav]

@eastmane the best option would really be to open a separate issue and share the repro if you could. Looking at these kinds of issues without more context is tricky as large number of problems may end up manifesting themselves with similar failures, which tends to be misleading. A good example of that was the issue @bmeijwaard ran into, which had the same exception, but it was caused by a parsing and mapping issue recently introduced in the runtime.

[eastmane]

Thanks for your help - have opened a separate issue, I can't post repro on here as it's part of a larger project but can probably share privately.

[fabiocav]

Thank you. Will continue following up on the newly created issue. For the repro, I'd be happy to look at something shared privately as well. My email is available on my GitHub profile.

[metoule]

The problem is caused by invalid expression in _FunctionsPostBuildDepsCopy target (in ...packages\microsoft.net.sdk.functions\3.0.1\build\Microsoft.NET.Sdk.Functions.Build.targets)

<Target Name="_FunctionsPostBuildDepsCopy" AfterTargets="PostBuildEvent" Condition="'$(SkipFunctionsDepsCopy)' != 'true'">
    <Copy SourceFiles="$(OutDir)$(ProjectName).deps.json" DestinationFiles="$(OutDir)bin\function.deps.json" Condition="Exists('$(OutDir)$(ProjectName).deps.json')"/>
  </Target>

It relies on $(ProjectName) which is not correct. It should be $(AssemblyName). You are not able to reproduce the issue on 'Hello World' application, because both MSBuild variables have the same value.

The same issue is present in Microsoft.NET.Sdk.Functions.Publish.targets:

<Target Name="_FunctionsPublishDepsCopy" BeforeTargets="Publish" Condition="'$(SkipFunctionsDepsCopy)' != 'true'">
    <Copy SourceFiles="$(PublishDir)$(ProjectName).deps.json" DestinationFiles="$(PublishDir)bin\function.deps.json" Condition="Exists('$(PublishDir)$(ProjectName).deps.json')"/>
</Target>

which causes an issue when deploying on Azure.

[fabiocav]

@metoule that issue has been addressed and the package is pending deployment. If you'd like to validate, you can consume the package from here in the meantime: https://www.myget.org/feed/azure-appservice-staging/package/nuget/Microsoft.NET.Sdk.Functions/3.0.3

/cc @brettsam

[lars-erik]

@fabiocav I just resolved this by installing 3.0.3 from staging. Looks good! 🙂👍

[ldfloresgon]

@fabiocav it seems fixed with Microsoft.NET.Sdk.Functions -Version 3.0.2 isn't it?

[curelom]

Negative. I've installed Microsoft.NET.Sdk.Functions Version 3.0.2 and it still doesn't work. I have also pulled in and used Version 3.0.3 from staging as mentioned above and it STILL doesn't work. This issue should not have been closed. Please re-open

[ldfloresgon]

@curelom you must clean and rebuild the solution and will work fine

[curelom]

No good. Cleaned the solution, even deleted bin and obj folders. Still get System.Data.SqlClient is not supported on this platform.

[ldfloresgon]

@curelom you should use microsoft.data.sqlclient instead of system.data.sqlclient

[curelom]

@ldfloresgon Thank you for that catch. I had referenced that as SqlParameter in one class. I have removed that now and get the System.PlatformNotSupportedException: Microsoft.Data.SqlClient is not supported on this platform error

[mjhoffmeister]

I was able to get everything working after switching to Microsoft.Data.SqlClient, then uninstalling System.Data.SqlClient and doing a clean/rebuild. I initially upgraded to Microsoft.NET.Sdk.Functions 3.0.3, but I just reverted to 3.0.2; everything is still working.

[OwenPattison]

Im using .Net Core 2.2 and I have updated the Microsoft.NET.Sdk.Functions from 1.0.29 to 1.0.31 and I also see Microsoft.Data.SqlClient is not supported on this platform error.

Reverting the package to 1.0.29 solves the problem for me while im using .Net Core 2.2 however from what I can see this is not listed as a breaking change which I feel it should be.

[bestcoder]

@metoule that issue has been addressed and the package is pending deployment. If you'd like to validate, you can consume the package from here in the meantime: https://www.myget.org/feed/azure-appservice-staging/package/nuget/Microsoft.NET.Sdk.Functions/3.0.3

/cc @brettsam

FWIW, I tried the 3.03 package in my azure function project that is getting the error and there was no change. The error still occurs. I also tried the Microsoft.NET.Sdk.Functions.3.0.4 package and the error still occurs with that. My project is targeting '.NETFramework,Version=v4.8'

[daunish]

I am still seeing this issue also. I am migrating from Core 2.2 to Core 3.1 I've upgraded all packages to the latest - the functions sdk is a 3.0.3 I set the functions runtime to v3 in my csproj file The project is targeting .NETStandard 2.1

Confirmed my function app is running a ~3.x runtime:

I see this when I try to execute a function:

2020-02-22T09:47:30.676 [Error] Executed '<FUNCTION-NAME>' (Failed, Id=2423fc5a-397a-44f6-a6d2-9b6e2636ce1e) Microsoft.Data.SqlClient is not supported on this platform.

What's a bit concerning here is that it is trying to use the correct client (Microsoft.Data.SqlClient) but it's not working. Would love some guidance on how to get around this...

[daunish]

I was able to get this working by downgrading the functions sdk to 3.0.2 (which is odd considering the fix was supposed to go to into 3.0.3) And I changed the target to netcoreapp3.0 - when I tried netcoreapp3.1 it did not work.

[jadenrogers]

@daunish had same issue and is now working on 3.0.5 - netcoreapp3.0

[c-lamont]

Hi, I've been trying all the tips in this thread so far for a whole day but still getting Microsoft.Data.SqlClient is not supported on this platform.

It has been working for the past couple of years and only when I updated my .Net Core version did this error start appearing (I believe). Here are my installed .Net Core versions.

2.1.202 [/usr/local/share/dotnet/sdk]
3.1.100 [/usr/local/share/dotnet/sdk]
3.1.101 [/usr/local/share/dotnet/sdk]
3.1.102 [/usr/local/share/dotnet/sdk]
3.1.200 [/usr/local/share/dotnet/sdk]

Microsoft.NET.sdk.functions: 3.0.6 (Also tried 3.0.2 as suggested) Microsoft.Data.SqlClient: 1.1.2 MacOS: 10.15.4 Visual Studio Mac: 8.5.3

Any further advice would be greatly appreciated.

Edit: Started happening to my colleague. Everyone scared to change anything now. Is this an actual bug or are we all doing something wrong?

[WinInsider]

To overcome "Microsoft.Data.SqlClient is not supported on this platform" exception in Azure (Linux) without using "Microsoft.NET.Sdk.Functions" nuget package, do the following (in csproj file).

1) create (mkdir) "bin" folder (under publish folder) 2) move $(AssemblyName).deps.json to "bin" folder; with new file name: function.deps.json 3) move "runtimes" folder under "bin" folder

Targeting netcoreapp3.1 and Function Runtime v3 (Azure defaults to 3.0.13113)

[paulbatum]

Just a quick note - we consider the Microsoft.NET.Sdk.Functions NuGet package as a required part of the .NET developer experience for Azure Functions. We do not test or support scenarios where this package has been removed.