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]

[marc-wilson]

I don't know if this is the reason or not, but the https://github.com/dotnet/sqlclient docs suggest 3.0 isn't supported?

Supportability
The Microsoft.Data.SqlClient package supports the below environments:

.NET Framework 4.6+
.NET Core 2.1+
.NET Standard 2.0+.
The source code of this library is now available under the MIT license.

But I'm not sure why my web app projects running 3.0 works and the function app does not...

[smairo]

We have this same exact problem

[ngg]

I had this problem on .NET Core 2.1, Functions ~2, when I tried to update to Microsoft.Data.SqlClient from System.Data.SqlClient. It worked when I tried locally using func on Linux, but failed with this exception in the cloud.

[marc-wilson]

@ngg That's the thing. I haven't imported that anywhere. It's packaged with Entity Framework from what I can tell. Upgrading/downgrading that package isn't an option.

[paulbatum]

I think I know what is going on here. Try adding the following to your .csproj:

<Target Name="PostBuild" AfterTargets="PostBuildEvent">
    <Exec Command="copy $(OutDir)$(ProjectName).deps.json $(OutDir)bin\function.deps.json" />
  </Target>
  <Target Name="PostPublish" BeforeTargets="Publish">
    <Exec Command="copy $(PublishDir)$(ProjectName).deps.json $(PublishDir)bin\function.deps.json" />
  </Target>

(in the future this workaround should not be necessary)

[marc-wilson]

@paulbatum Thanks.

For anyone else having this issue and working on a mac, I had to modify what @paulbatum provided a little bit:

  <Target Name="PostBuild" AfterTargets="PostBuildEvent">
    <Exec Command="cp $(OutDir)Chadwick.$(ProjectName).deps.json $(OutDir)/bin/function.deps.json" />
  </Target>
  <Target Name="PostPublish" BeforeTargets="Publish">
    <Exec Command="cp $(PublishDir)Chadwick.$(ProjectName).deps.json $(PublishDir)/bin/function.deps.json" />
  </Target>

$(ProjectName) wasn't correct for me. It wanted the namespace I guess? In any case, aside from windows copy command needing to be cp on a mac along with minor path updates, this workaround unblocks me. Thanks, @paulbatum

[kaeus]

@paulbatum I've attempted to use this solution with no luck. I've verified that when deployed the functions.deps.json is present and accurate, however I still get the same exception as above.

I have tried a few setups to verify that the issue happens regardless of if my Azure Function project directly references Microsoft.Data.SqlClient or not. Any other suggestions if this workaround doesn't solve the issue?

[IGx89]

@kaeus you're probably hitting Azure/azure-functions-vs-build-sdk#333. You're also need to add the following to work around that .NET Core 3.0 SDK bug:

  <Target Name="PostPublish" AfterTargets="AfterPublish">
    <Exec Command="move $(PublishDir)\runtimes $(PublishDir)\bin" />
  </Target>

@paulbatum that's awesome that there's hope for that not being needed in the future. Do you have an issue, version, and/or ETA for the fix? There's a long (closed but active) issue, Azure/azure-functions-host#3568, with lots of people reporting the issue but no updates from Microsoft so it was seeming this wasn't ever going to be fixed.

[kaeus]

@IGx89 Thanks, that seems to have wrapped up the issue for me (combining that with the previous solutions)!

[huwparry22]

I'm having a few problems with this work around. I can see the file getting copied to the output directory with the relevant detail to function.deps.json, but my DI assembly scanning is then failing to pick up all of my dependencies. This is my assembly scanning code that then registers the dependencies using Scrutor with the built in .NET Core DI Container:-

            string path = Path.GetDirectoryName(Assembly.GetCallingAssembly().Location);
            List<Assembly> assemblies = new List<Assembly>();
            foreach (string dll in Directory.GetFiles(path, "MyNamespace*.dll"))
            {
                assemblies.Add(Assembly.LoadFrom(dll));
            }

            services.Scan(scan => scan
                .FromAssemblies(assemblies)
                .AddClasses(classes => classes.Where(types => types.FullName.StartsWith("MyNamespace.")))
                .UsingRegistrationStrategy(RegistrationStrategy.Append)
                .AsMatchingInterface()
                .WithTransientLifetime()
            );

I've tried the copy command with the actual name of the file too (as opposed to the name function.deps.json) but I'm still not able to resolve my dependencies, despite all the dependencies being configured.

Apologies for this not quite being related to the main problem but it's the only place I could ask the question.

Thanks

[iRubens]

For anyone hitting this problem on "zip deployed" (from Visual Studio) azure functions the final .csproject section required is the following:

<Target Name="PostBuild" AfterTargets="PostBuildEvent">
  <Exec Command="copy $(OutDir)$(ProjectName).deps.json $(OutDir)bin\function.deps.json" />
</Target>
<Target Name="PostPublish" BeforeTargets="Publish">
  <Exec Command="copy $(PublishDir)$(ProjectName).deps.json $(PublishDir)bin\function.deps.json" />
  <Exec Command="move $(PublishDir)\runtimes $(PublishDir)\bin" />
</Target>

@IGx89 your suggestion fixed the problem, but with "zip deployed" azure functions the directory move was being done after the publishing.

[IGx89]

@iRubens all my functions are zip deployed as well but the zipping is done as a separate command after dotnet publish, right before I POST the zip to Azure. It sounds like you know of a way to get the dotnet CLI to zip up the publish folder for you as well? If so I'd love to know how to do that, I've had zero luck finding out how to do that myself.

[kaeus]

@iRubens all my functions are zip deployed as well but the zipping is done as a separate command after dotnet publish, right before I POST the zip to Azure. It sounds like you know of a way to get the dotnet CLI to zip up the publish folder for you as well? If so I'd love to know how to do that, I've had zero luck finding out how to do that myself.

If you are using Azure DevOps to publish with the DotNetCoreCLI task you can set zipAfterPublish to true that should do that automatically. I don't know of any way to do that via dotnet publish alone without an extra step.

[iRubens]

@IGx89 at the moment we're deploying our functions directly from Visual Studio (I've updated my comment). Unfortunately don't know either if there's any command for the CLI to obtain the same result.

[brettsam]

For those of you working around this -- the deps.json file should now be auto-copied when using Microsoft.NET.Sdk.Functions version 3.0.0-preview1.

There is still a problem with having the runtimes folder moved to under the bin folder during publish -- I'm looking into that now, but the workaround above (#1370 (comment)) should work.

[shailendrarampal]

For anyone hitting this problem on "zip deployed" (from Visual Studio) azure functions the final .csproject section required is the following:

<Target Name="PostBuild" AfterTargets="PostBuildEvent">
  <Exec Command="copy $(OutDir)$(ProjectName).deps.json $(OutDir)bin\function.deps.json" />
</Target>
<Target Name="PostPublish" BeforeTargets="Publish">
  <Exec Command="copy $(PublishDir)$(ProjectName).deps.json $(PublishDir)bin\function.deps.json" />
  <Exec Command="move $(PublishDir)\runtimes $(PublishDir)\bin" />
</Target>

@IGx89 your suggestion fixed the problem, but with "zip deployed" azure functions the directory move was being done after the publishing.

My azure function stopped pubishing after adding above code to csproj file : https://stackoverflow.com/questions/58833050/azure-functions-runtime-exception-the-type-initializer-for-system-data-sqlclien

"Publish has encountered an error.
Publish has encountered an error. We were unable to determine the cause of the error."

[brettsam]

@shailendrarampal -- what OS are you running on? Note that you should not need the deps.json lines anymore when using 3.0.0-preview1.

[shailendrarampal]

@shailendrarampal -- what OS are you running on? Note that you should not need the deps.json lines anymore when using 3.0.0-preview1.

I am using windows 10 64bit!
But if you go through the link above, my real problem was 'sni.dll was not loded' with aspnet core 3.0 and azure function v3-preview with system.data.sqlclient version 4.7.0

[brettsam]

This line should be taking care of that: <Exec Command="move $(PublishDir)\runtimes $(PublishDir)\bin" /> Your stackoverflow post doesn't show that as included, so I'm not sure exactly what you're running -- do you have that in your csproj? Can you share your entire csproj?

[shailendrarampal]

This line should be taking care of that: <Exec Command="move $(PublishDir)\runtimes $(PublishDir)\bin" /> Your stackoverflow post doesn't show that as included, so I'm not sure exactly what you're running -- do you have that in your csproj? Can you share your entire csproj?

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFramework>netcoreapp3.0</TargetFramework>
    <AzureFunctionsVersion>v3-preview</AzureFunctionsVersion>
  </PropertyGroup>
  <ItemGroup>
    <PackageReference Include="Microsoft.ApplicationInsights.AspNetCore" Version="2.8.2" />
    <PackageReference Include="Microsoft.Data.SqlClient" Version="1.0.19269.1" />
    <PackageReference Include="Microsoft.NET.Sdk.Functions" Version="1.0.30-beta2" />
    <PackageReference Include="System.Data.SqlClient" Version="4.7.0" />
  </ItemGroup>
  <ItemGroup>
    <None Update="host.json">
      <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
    </None>
    <None Update="local.settings.json">
      <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
      <CopyToPublishDirectory>Never</CopyToPublishDirectory>
    </None>
  </ItemGroup>
  <ItemGroup>
    <PackageReference Include="Microsoft.ApplicationInsights.AspNetCore" Version="2.8.0" />
  </ItemGroup>

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

  <Target Name="PostBuild" AfterTargets="PostBuildEvent">
    <Exec Command="copy $(OutDir)$(ProjectName).deps.json $(OutDir)bin\function.deps.json" />
  </Target>
  <Target Name="PostPublish" BeforeTargets="Publish">
    <Exec Command="copy $(PublishDir)$(ProjectName).deps.json $(PublishDir)bin\function.deps.json" />
    <Exec Command="move $(PublishDir)\runtimes $(PublishDir)\bin" />
  </Target>
  
</Project>

[shailendrarampal]

This line should be taking care of that: <Exec Command="move $(PublishDir)\runtimes $(PublishDir)\bin" /> Your stackoverflow post doesn't show that as included, so I'm not sure exactly what you're running -- do you have that in your csproj? Can you share your entire csproj?

It worked for me by adding below code in csproj file :

<Target Name="PostPublish" BeforeTargets="Publish">
  <Exec Command="move $(PublishDir)\runtimes $(PublishDir)\bin" />
</Target>

Thank you.

[brettsam]

I've just pushed Microsoft.Net.Sdk.Functions 3.0.0-preview2. I believe this package now handles all the problems mentioned in this issue. If you could try removing the workarounds and using that package, that'd be helpful. I'm going to close this now, but let me know if something hasn't been fixed and I can re-open (or create a separate issue).

[IGx89]

I can confirm both issues are fixed now for me (under Functions v3-preview, .NET Core SDK 3.0), thanks a lot @brettsam!

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

[WinInsider]

@paulbatum Microsoft.NET.Sdk.Functions NuGet package pulls A LOT dependencies. Not every consumer will make use of them all... For example, AspNetCore is pulled (indirectly via Microsoft.Azure.WebJobs.Extensions.Http). Azure Queue scenarios has no need for AspNetCore.

Consider separating MSBuld related task into separate package. Light, portably and not tying to any particular stack is very appealing to a lot of consumers. Regardless, focus on developer experience and integration is what set Azure apart from others !!! And makes it easy to use !!!

[paulbatum]

@WinInsider Yes what you're asking for makes sense, there is definite room for improvement in terms of the minimal dependency surface area when writing a .NET based function. Anyway I don't want to derail this thread further.

For the folks still reporting problems when running on the latest package (3.0.7 at time of writing) and targetting netcoreapp3.1, please file a new issue and link back to this one. Fill out the issue template and make sure you include additional relevant details such as the contents of your csproj.

[npnelson]

I have the problem with the 3.0.7 runtime, although I can only reproduce the problem when running in a container. Non container locally and in Azure seems to work fine, but I love containers, so it would be nice to get it working there too.

I commented with a github repo that can reproduce it when running with Visual Studio on this newer issue Azure/azure-functions-host#5950

[npnelson]

Interesting enough, I just tried within Visual Studio as a Release build and it worked fine. I am not sure why Release works and Debug doesn't. I was also able to successfully to successfully build the container from Azure Pipelines and run it in an Azure App Service Linux container instance.

I'm still not sure why it doesn't work for me with a Visual Studio debug build, but that isn't a big issue for me now since I can run it in production.

[bfmsoft]

I just confirmed that is in "Microsoft.NET.Sdk.Functions" Version="3.0.8". Move back to 3.0.7 and goes away.

[TheHokieCoder]

I just confirmed that is in "Microsoft.NET.Sdk.Functions" Version="3.0.8". Move back to 3.0.7 and goes away.

+1...been banging my head against my desk for several hours now trying to figure out why I was getting the platform not supported message when all indication was that it was working. After downgrading the SDK to v3.0.7, the SQL client is working.

HOWEVER, after digging around through some other things, I stumbled upon what may be a caveat or potentially a regression in the SDK tooling that I was able to work around and get the SqlClient package working with v3.0.8 of the SDK.

It appears to me that in v3.0.7, when you build your function app the build target places the runtimes directory under the bin directory (as mentioned earlier in this issue). The same happens when you publish the function app. But when you update the SDK to v3.0.8, the runtimes directory is left alongside the bin directory...not inside it...causing the exception. When you publish with v3.0.8, the runtimes directory is, in fact, moved into the bin directory and no exception occurs.

So with v3.0.8, my current workaround is to add a post-build target that is similar to what IGx89 mentioned in an earlier comment. Note, however, that the target is post-build, not post-publish. The difference with my approach is that the files are copied after build, which supports local debugging of your function app while also not stepping on the toes of what the publish target does. The downside is that there are multiple copies of runtime binaries in your build directories, but the upside is that this won't affect what is copied to the publish directory during that target.

  <Target Name="PostBuild" AfterTargets="AfterBuild">
    <Exec Command="xcopy /E /I /Q /Y $(OutDir)runtimes $(OutDir)bin\runtimes" />
  </Target>

The azure-functions-vs-build-sdk repository doesn't seem to be very well maintained in terms of tagging their releases and being transparent about what commits are going into which releases. As an example, see issue #438. I wasn't able to spend enough time to follow what changed from v3.0.7 to v3.0.8...but my hunch is that there was some sort of regression.

[pietervdheijden]

I just confirmed that is in "Microsoft.NET.Sdk.Functions" Version="3.0.8". Move back to 3.0.7 and goes away.

+1...been banging my head against my desk for several hours now trying to figure out why I was getting the platform not supported message when all indication was that it was working. After downgrading the SDK to v3.0.7, the SQL client is working.

HOWEVER, after digging around through some other things, I stumbled upon what may be a caveat or potentially a regression in the SDK tooling that I was able to work around and get the SqlClient package working with v3.0.8 of the SDK.

It appears to me that in v3.0.7, when you build your function app the build target places the runtimes directory under the bin directory (as mentioned earlier in this issue). The same happens when you publish the function app. But when you update the SDK to v3.0.8, the runtimes directory is left alongside the bin directory...not inside it...causing the exception. When you publish with v3.0.8, the runtimes directory is, in fact, moved into the bin directory and no exception occurs.

So with v3.0.8, my current workaround is to add a post-build target that is similar to what IGx89 mentioned in an earlier comment. Note, however, that the target is post-build, not post-publish. The difference with my approach is that the files are copied after build, which supports local debugging of your function app while also not stepping on the toes of what the publish target does. The downside is that there are multiple copies of runtime binaries in your build directories, but the upside is that this won't affect what is copied to the publish directory during that target.

  <Target Name="PostBuild" AfterTargets="AfterBuild">
    <Exec Command="xcopy /E /I /Q /Y $(OutDir)runtimes $(OutDir)bin\runtimes" />
  </Target>

The azure-functions-vs-build-sdk repository doesn't seem to be very well maintained in terms of tagging their releases and being transparent about what commits are going into which releases. As an example, see issue #438. I wasn't able to spend enough time to follow what changed from v3.0.7 to v3.0.8...but my hunch is that there was some sort of regression.

@TheHokieCoder This worked for me! Thanks a ton :)

[flatproject]

Downgrading to 3.0.7 worked for me

[Gabsch]

For the folks still reporting problems when running on the latest package (3.0.7 at time of writing) and targetting netcoreapp3.1, please file a new issue and link back to this one. Fill out the issue template and make sure you include additional relevant details such as the contents of your csproj.

@paulbatum Do we need a new issue for 3.0.8 or are you guys aware of the problem?

[bbakermmc]

Azure is such a shit show, they break stuff every minor patch and you spend hours or days trying to figure out wtf is going on. Its like basically never upgrade your packages.

[brettsam]

This was an issue with the build tooling that came with 3.0.8 -- Issues and PR are here:

• Microsoft.Data.SqlClient is not supported on this platform with Microsoft.NET.Sdk.Functions 3.0.8 azure-functions-vs-build-sdk#436
• Version 3.0.8 places the runtimes folder incorrectly azure-functions-vs-build-sdk#437
• Copying the runtime folder as part of post build step azure-functions-vs-build-sdk#443

[c-lamont]

My fix was changing my project from

<TargetFramework>netstandard2.0</TargetFramework>
<AzureFunctionsVersion>v2</AzureFunctionsVersion>

To

<TargetFramework>netcoreapp3.1</TargetFramework>
<AzureFunctionsVersion>v3</AzureFunctionsVersion>

Then updating package Microsoft.NET.Sdk.Functions to v 3.0.7

[alnintex]

Microsoft.NET.Sdk.Functions to v 3.0.9 fixed the problem

[TechWatching]

Can't upgrade to v3.0.9 because of this issue :(

[frasparacio]

Still having the same problem with Microsoft.NET.Sdk.Functions v. 3.0.9.
Just migrating from .net core 2.2 to 3.1 and this was one of the problems we had.
Solved putting postbuild and postpublish command as suggested above, thanks!

[ZooDoo4U]

So i just ran into the issue, easy to understand if this is beta, but isn't everything with issues officially released at first it seems looking at the date of the original post this has been going on for over a year now? Last comment only 10 hours ago...

[anthonychu]

@brettsam Do you know what could still be causing this?

@ZooDoo4U Can you solve it using the post build and post publish commands above?

[fabiocav]

@anthonychu to understand what is happening, we'd need the details.

@ZooDoo4U can you please open a new issue with details of all version used, exception stacks, etc? we can take a closer look then.

Will lock this issue as there have been tooling and runtime updates to address the original root cause, so any new instances will need to be investigated separately.

[brettsam]

Please include your csproj in the repro as that helps determine what could be going on.

[cgillum]

If anyone runs into this while using the functions CLI to install extensions (func extensions install) that depend on Microsoft.Data.SqlClient, I was able to work around this by updating my extensions.csproj file to look like the following:

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFramework>netcoreapp3.1</TargetFramework>
    <WarningsAsErrors></WarningsAsErrors>
    <DefaultItemExcludes>**</DefaultItemExcludes>
  </PropertyGroup>

  <!-- Workaround for https://github.com/Azure/Azure-Functions/issues/1370 -->
  <Target Name="PostBuild" AfterTargets="PostBuildEvent">
    <Move SourceFiles="$(OutDir)/extensions.deps.json" DestinationFiles="$(OutDir)/function.deps.json" />
  </Target>

  <ItemGroup>
    <!-- ...(other dependencies)... -->
    <PackageReference Include="Microsoft.Data.SqlClient" Version="3.0.0" />
  </ItemGroup>
</Project>

This workaround specifically applies to C# scripting and non-.NET languages which aren't using extension bundles.