Microsoft.Azure.WebJobs.Extensions.Http depends on deprecated "Microsoft.AspNetCore.*" packages

[fowl2]

Microsoft.Azure.WebJobs.Extensions.Http (3.2.0, the current version) is a direct dependency of Microsoft.NET.Sdk.Functions ie. the main Functions SDK, which means it is included in all in-proc Functions.

And it depends on several deprecated packages:

• Microsoft.AspNetCore.Http (>= 2.2.2)
• Microsoft.AspNetCore.Mvc.Formatters.Json (>= 2.2.0)
• Microsoft.AspNetCore.Mvc.WebApiCompatShim (>= 2.2.0)
• Microsoft.AspNetCore.Routing (>= 2.2.2)

There were announced deprecated by the .Net team at dotnet/announcements#217 (discussion: dotnet/core#7420) in May 2022.

This dependency has caused at least one issue: https://github.com/MicrosoftDocs/azure-docs/issues/54934.

It would be great if it could be removed.

[Havunen]

This is annoying issue because the main function app SDK depends on Microsoft.Azure.WebJobs.Extensions.Http
and certain things (like new extension methods) does not work as expected. https://www.nuget.org/packages/Microsoft.NET.Sdk.Functions

[patelriki13]

Any updates on this?
Critical vulnerabilities and deprecated packages still low priorities?
After 6 months, is there no progress on this?

[lzandman]

Still no progress. This issue is flagged in our SCA tooling. Technically you're requiring us to run vulnerable software, which, as The Mandalorian would say it, isn't the way...

[bhagyshricompany]

Hi @jviau please comment.Thanks

[jviau]

AspNetCore no longer ships these packages out of band. We would need to add an AspNetCore Framework reference to address this. However, it is fully in the end users' power to uplift this package to by adding <FrameworkReference Include="Microsoft.AspNetCore.App" /> to their csproj, which will pin this package to the version shipped with the aspnetcore runtime (so it will match your TFM). Additionally, for function apps the real package versions loaded at runtime are the current ones for the TFM. So when running .net6 in-proc functions, we will be loading all the 6.x versions, and similarly for net8 in-proc it is 8.x.

Given the workaround and that these packages are only compile-time dependencies (with later versions used at runtime), we do not intend to address this.