Consider moving ASPNETCORE_HTTP_PORTS env variable from runtime-deps Dockerfile to aspnet Dockerfile

[Varorbc]

Describe the Problem

The ASPNETCORE_HTTP_PORTS environment variable is currently defined in the runtime-deps Dockerfile (e.g., src/runtime-deps/11.0/alpine3.23/amd64/Dockerfile). This is not ideal because consumers of the runtime-deps image may not be using ASP.NET Core, so including this environment variable in a base image can be confusing or misleading.

Describe the Solution

It would be more appropriate to define ASPNETCORE_HTTP_PORTS only in Dockerfiles intended specifically for ASP.NET or ASP.NET Core. This will improve the clarity and generality of the runtime-deps image by not including env variables that don't apply to all consumers.

Additional Context

Reference: src/runtime-deps/11.0/alpine3.23/amd64/Dockerfile#L7

[lbussell]

The purpose of the dotnet/runtime-deps image is to allow users to publish their self-contained or Native AOT compiled .NET apps. Those can use ASP.NET Core or not, and we have no way of knowing. So including the ASPNETCORE_HTTP_PORTS environment variable in the runtime-deps image gives users a consistent experience between the all of the different deployment models for ASP.NET Core.

[lbussell]

[Triage] Closing this issue because this is by design.

[Varorbc]

@lbussell

Thank you for the explanation. I understand the intention to provide a consistent ASP.NET Core experience across different deployment models, including self-contained and Native AOT scenarios. However, I would like to offer several additional considerations that may warrant revisiting this design decision:

1. Minimalism and clarity of the runtime-deps image

The purpose of runtime-deps is generally understood to be a minimal base image containing only the native dependencies required to run a published .NET application.
Including an ASP.NET Core–specific environment variable in this image introduces behavior that is not universally applicable and may confuse users who are not deploying web workloads.
Keeping runtime-deps minimal and framework-agnostic would better align with its intended role.

2. Potential for a more explicit split

If ASP.NET Core defaults are required for AOT or self-contained web apps, an alternative could be to introduce a more explicit separation, such as:

• a pure runtime-deps image (no ASP.NET Core–specific defaults), and
• a runtime-deps-aspnet (or similar) variant that includes ASP.NET Core–related environment variables.
  This would preserve consistency for ASP.NET Core users while avoiding unnecessary assumptions for others.

3. Environment variables could be set directly in the generated Dockerfile

For ASP.NET Core AOT or self-contained web applications, the required environment variables can be added explicitly in the Dockerfile generated by the tooling.
This approach keeps the base image clean while still ensuring that ASP.NET Core applications receive the correct configuration when a Dockerfile is produced for them.