Dotnet Core Buildpack does not handle cgroup v2 memory limits correctly – app does not release memory properly

Summary

When deploying a .NET application using this buildpack on a Linux system with cgroup v2, the application does not respect memory limits and fails to release memory correctly under memory pressure. This causes memory bloat and eventually OOM kills, even though GC should release memory.

Steps to Reproduce

1. Use the current (latest) version of dotnet-core-buildpack to deploy a .NET 8 application,
   CF API Version 2.255.0
   stack: cflinuxfs4
   buildback: dotnet-core-buildpack-cflinuxfs4-v2.4.40.zip
2. Run it on a container or host using Linux with cgroup v2 enabled (e.g., Ubuntu 22.04)
3. Observe memory usage growing over time, not reclaimed by GC
4. Monitor with e.g top/htop

Expected Behavior

The .NET GC should properly respond to memory pressure and release memory back to the system when not needed.

Actual Behavior

Memory usage keeps growing, and the process does not appear to honor memory limits or GC signals under cgroup v2.

Diagnosis

This appears to be caused by the fact that the buildpack uses .NET without the necessary environment variables or configuration to enable full cgroup v2 memory awareness. This affects how the GC calculates available memory.

Start by reproducing the issue with a .NET 8 application on Linux with cgroup v2 enabled, using the buildpack version and Cloud Foundry details in the report. Inspect the buildpack's runtime configuration and compare memory-limit behavior with cgroup v2; done means the application honors the limit and releases memory under pressure without an OOM kill.