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

[HughPH]

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.DiagnosticPort": "disabled",
      ... etc
    }
  }
}

Alternative Designs

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

[dotnet-policy-service]

Tagging subscribers to this area: @tommcdon
See info in area-owners.md if you want to be subscribed.

[teo-tsirpanis]

This could be added to the existing DebuggerSupport option, which already removes information to make debugging easier.

to be baked into the published code, and not overridable

I'm not sure if this is even possible. If you make a self-contained deployment of your app, that comes with a specially compiled runtime that has diagnostics support completely ripped out, somebody can easily replace it with the stock runtime binaries.

[HughPH]

This could be added to the existing DebuggerSupport option, which already removes information to make debugging easier.

That sounds entirely reasonable to me - the risk would be that someone is actually using it with a !(better debugging experience), whatever that might look like. If there is a debugging experience of any sort, then removing it entirely would be a breaking change.

to be baked into the published code, and not overridable

I'm not sure if this is even possible. If you make a self-contained deployment of your app, that comes with a specially compiled runtime that has diagnostics support completely ripped out, somebody can easily replace it with the stock runtime binaries.

That's a fair comment: if you can get hold of the exe, you can do anything at all with it, even just decompile it and make your own. Even if this setting appears in runtimeconfig, a self-contained exe can be unpacked and the runtimeconfig modified.

I'm thinking more of just making what's been deployed behave as designed by developers and architects, and not behave differently due to, say, someone well-meaning down the line stripping things out that they don't understand.