[API Proposal]: A mechanism for disabling managed debugging at compile time

Start by tracing the EnableDiagnostics entries in clrconfigvalues.h and how RuntimeHostConfigurationOption values reach runtimeconfig.json. Clarify whether the setting must affect the runtime server as well as the launch side, and determine what compile-time or publish-time behavior is intended. Done should mean diagnostics cannot be re-enabled through deployment configuration, with the behavior covered by appropriate runtime tests.

Background and motivation

Let's imagine I'm building a package to be "thrown over the wall" to some other team who will deal with building a Docker image. Or that I've written my Dockerfile myself and it'll go to some other team to actually package it and deploy it. Or that the organisation is relatively immature and I've just been asked to provide the binaries and instructions for how to create a service on a big ol' server. Or that we provide an unusual level of freedom to our customers to put services wherever they want, and they can launch them however they want, as services, as startup scripts, whatever, we don't care.

We potentially find ourselves in situations where the DOTNET_EnableDiagnostics env var might not be set to 0 in situations where we really want the DOTNET_EnableDiagnostics env var to be set to 0.

What I would like is a mechanism for the equivalent behaviour to be baked into the published code, and not overridable.

API Proposal

Not sure this is relevant for this suggestion.

API Usage

We'd probably want the configuration to find its way into runtimeOptions, and we'd do that by making an ItemGroup in the project file or Directory.Build.props:

<ItemGroup Condition=" '$(IsPublish)' == 'true' ">
  <RuntimeHostConfigurationOption Include="System.Diagnostics.EnableDiagnostics">
    <Value>false</Value>
  </RuntimeHostConfigurationOption>
</ItemGroup>

Which would come out in the runtimeconfig.json like:

{
  "runtimeOptions": {
    "tfm": "net9.0",
    "includedFrameworks": [
      {
        "name": "Microsoft.NETCore.App",
        "version": "9.0.3"
      }
    ],
    "configProperties": {
      "System.Diagnostics.EnableDiagnostics": "false",
      ... etc
    }
  }
}

Alternative Designs

Maybe some hint to the compiler that it can drop the code entirely and shake it out of the tree altogether? I don't know how embedded the diagnostics code is, whether it's abstracted, and whether abstraction, if required, would potentially introduce performance degradation.

I'm not entirely certain what I'm looking at, but I find the following in clrconfigvalues.h

///
/// Debugger, Profiler, Diagnostics IPC Ports
///
RETAIL_CONFIG_DWORD_INFO(EXTERNAL_EnableDiagnostics, W("EnableDiagnostics"), 1, "Allows the debugger, profiler, and diagnostic IPC service ports to be disabled")
RETAIL_CONFIG_DWORD_INFO(EXTERNAL_EnableDiagnostics_IPC, W("EnableDiagnostics_IPC"), 1, "Allows the diagnostic IPC service ports to be disabled")
RETAIL_CONFIG_DWORD_INFO(EXTERNAL_EnableDiagnostics_Debugger, W("EnableDiagnostics_Debugger"), 1, "Allows the debugger to be disabled")
RETAIL_CONFIG_DWORD_INFO(EXTERNAL_EnableDiagnostics_Profiler, W("EnableDiagnostics_Profiler"), 1, "Allows the profiler to be disabled")

These seem to be hooked up on the LS, and this is where my understanding completely falls apart, because it looks to me like the ports are hosted in the RS, for the debugger to attach to? So how can we disable them on the LS?!?

Anyway, maybe these can be used to control availability of debugging on RS as well? IDK.

Risks

No response