Support standard ASP.NET Core applications without Functions-specific attributes

[zameb]

What problem would the feature you're requesting solve? Please describe.

Currently, Azure Functions requires decorating HTTP endpoints with Functions-specific attributes ([FunctionName], [HttpTrigger]), which creates vendor lock-in and prevents using standard ASP.NET Core controllers.

This forces developers to choose between:

1. Standard ASP.NET Core (portable, but no Functions deployment)
2. Functions-specific code (serverless, but locked to Azure)

Describe the solution you'd like

Azure Functions runtime should support deploying standard ASP.NET Core applications without code modifications. The runtime should:

1. Detect standard ASP.NET Core projects (Program.cs, Controllers)
2. Host Kestrel within the Functions runtime
3. Route HTTP triggers to the ASP.NET Core pipeline transparently

Configuration (scaling, billing, lifecycle) remains in infrastructure (host.json, ARM templates), NOT in code.

Describe alternatives you've considered

• Container Apps: Works but loses Functions-specific features
• Adapter pattern: Adds boilerplate and maintenance burden
• AWS Lambda Web Adapter: Already solves this problem

Additional context

.NET Core's value proposition is portability and open standards.
Requiring Functions-specific attributes contradicts this philosophy.

The same code should deploy to:

• Azure Functions
• App Service
• Container Apps
• IIS
• Standalone Kestrel

Deployment target should be infrastructure concern, not application code.

[jviau]

Ah misread the feature request, thought this was related to dotnet worker but it is a separate worker, so does belong in the host repo.

[jviau]

@zameb, we did add some public extensibility points to the dotnet isolated worker which would allow for using AspNetCore endpoints (minimal APIs, MVC) and exposing them directly. You would still need to bootstrap the application as a function app in your Program.cs. But you wouldn't need to use [HttpTrigger] attributes. Would that be acceptable to you? Realized while we could discover the endpoints, we won't have the APIs to register AspNetCore endpoints available.

An alternative would be you could use a custom worker with HTTP proxying and point a catch-all route to your worker. Then you could just use a basic AspNetCore app as your worker. That is possible today.

[fabiocav]

There's also some work planned to better support this scenario. Timelines for that are not concrete enough to share, but we're looking at an experience that aligns with the ASP.NET Core dev experience on Functions in the short-medium term.

I'll keep this open as a feature request.