Description
I'd be great if Azure Functions v4 (isolated) could support the standard ASP.NET Core request pipeline (routing + middleware), instead of requiring HTTP triggers for each endpoint.
Right now there’s a mismatch between the Functions model and how most ASP.NET Core apps are structured. This makes it harder to port existing apps or share middleware, and leads to a lot of adaptation code because it's not ASP.NET Core idiomatic. Copilot gets very confused for example.
A possible approach would be to allow opting into an ASP.NET Core pipeline that’s backed by a single catch-all HTTP trigger internally, and then dispatches through UseRouting / endpoint mappings as usual. From the developer side this would look like a normal ASP.NET Core app (controllers, minimal APIs, middleware, etc.) running inside the Functions host.
This would make a few scenarios easier:
- running ASP.NET Core apps with scale-to-zero, without having to maintain containers
- migrating existing ASP.NET Core applications with minimal changes
- adding mixing HTTP endpoints with other triggers (timers, queues, etc.)
With the isolated worker model we're already 90% of the way there, so it'd be great to go all the way to finishing bridging the gap,
Alternatives
The HTTP and Non-HTTP components of the app could be split into seperate Function apps.
- ASP.NET Core app as a Custom Handler in HTTP Only mode with a created manually catch all Http Trigger.
- A regular Function app without ASP.NET Core integration for all the non Http triggers.
This is a bit messy - manual steps, twice the deployments, config drift, etc.
Description
I'd be great if Azure Functions v4 (isolated) could support the standard ASP.NET Core request pipeline (routing + middleware), instead of requiring HTTP triggers for each endpoint.
Right now there’s a mismatch between the Functions model and how most ASP.NET Core apps are structured. This makes it harder to port existing apps or share middleware, and leads to a lot of adaptation code because it's not ASP.NET Core idiomatic. Copilot gets very confused for example.
A possible approach would be to allow opting into an ASP.NET Core pipeline that’s backed by a single catch-all HTTP trigger internally, and then dispatches through UseRouting / endpoint mappings as usual. From the developer side this would look like a normal ASP.NET Core app (controllers, minimal APIs, middleware, etc.) running inside the Functions host.
This would make a few scenarios easier:
With the isolated worker model we're already 90% of the way there, so it'd be great to go all the way to finishing bridging the gap,
Alternatives
The HTTP and Non-HTTP components of the app could be split into seperate Function apps.
This is a bit messy - manual steps, twice the deployments, config drift, etc.