And we’re doing to also support DOTNET_ right? I should file an issue for that

Honestly, I don't see the point in having both besides the fact that COMPlus_ has been the convention in the runtime for so long. I'm inclined to just use DOTNET_, but I am willing to do both. Thoughts?

+1 for DOTNET_

but I am willing to do both. Thoughts?

My suggestion, optimize for easy implementation here. I suspect not supporting both will be the easier course.

It is a trivial change to make the environment variable DOTNET_DotnetDiagnosticsServerAddress and still use all the CLRConfig::* niceties (I have a commit locally that makes the change). I'm leaning towards the DOTNET prefix since we are expecting this to be used in heterogeneous environments and DOTNET identifies the variable as belonging to our ecosystem, while COMPlus feels unique to configuring the runtime.

Honestly, I don't see the point in having both besides the fact that COMPlus_ has been the convention in the runtime for so long.

Should we just stick to DOTNET_ prefix for any other environment variables related to Tracing/DiagnosticsServer that we add from now on then? (plus add them for any of the existing COMPlus_ variables) I think it might be confusing to users to have a mixture of COMPlus and DOTNET all over the place.

I think it makes sense to use DOTNET_ for variables we intend for customers to use in the context of application logging, metrics, and eventing. We aren't necessarily configuring the runtime in those cases, we are performing an application wide service that impacts the whole stack including customer code. I'm not sure if there are any current variables that I think we should need to modify, but I haven't audited them all.

/cc @lateralusX

@richlander do you have any thoughts on the prefix from an ecosystem perspective?