azure-functions-openapi-extension

azure-functions-openapi-extension copied to clipboard

I'm a bit puzzled as why to use this package (Microsoft.Azure.Functions.Worker.Extensions.OpenApi) when I still also need the Microsoft.Azure.WebJobs.Extensions.OpenApi package.

Most likely I'm missing the point ;)

I'm using it in my .NET 7 isolated Azure Function. I was under the impression I need to replace all Microsoft.Azure.WebJobs.* packages with Microsoft.Azure.Functions.Worker.*. That's why I found this package. But nothing changes when I add this package, because I still can't remove the Microsoft.Azure.WebJobs.Extensions.OpenApi package.

Please clarify.

@pmeems Thanks for the issue! You're almost there. There are a few things you need to change including the NuGet packages, host.json, local.settings.json, etc.

Before going further, would you please take a look at the sample app in this repo targeting the isolated worker environment? And let me know what the differences are?

Thanks for the quick reply. I just looked at your sample app (https://github.com/Azure/azure-functions-openapi-extension/tree/main/samples/Microsoft.Azure.Functions.Worker.Extensions.OpenApi.FunctionApp.OutOfProc) and I have similar content for local.settings.json and host.json. I noticed you're using Microsoft.Azure.WebJobs.Extensions.OpenApi.Core.Attributes and Microsoft.Azure.WebJobs.Extensions.OpenApi.Core.Enums with your functions (like UserHttpTrigger.cs ) as well.

So it seems I do need those Microsoft.Azure.WebJobs.* packages.

Am I correct?

@pmeems Were you able to find an answer to this? We're in the process of migrating our in-process workers to isolated workers, and we have this same confusion.

Hi Steve,

Unfortunately, we didn't manage to resolve this issue. After thorough attempts, we opted to remain with the in-process .NET 6 version. This choice was influenced by the considerable adjustments required on Azure's end, which proved to be a challenging endeavor impeding our progress.

Moreover, we recall stumbling upon insights (though the source eludes us presently) indicating substantial transformations and enhancements were on the horizon for isolated functions. This revelation was made in January; hence, we are optimistic that these advancements have since materialized. However, we admit to not having undertaken a recent evaluation.

As a unified decision within our team, we opted to postpone further attempts until the release of .NET8. We believe that by that time, any outstanding issues and limitations might have been addressed, making the transition smoother and more productive for our use case.