TraceSwitch value is not read from config

[aliostad]

Description

Unlike what docs TraceSwitch value is not read from app.config.

I have created a repro here: https://github.com/aliostad/TraceSwitchDoesNotWork

Reproduction Steps

Add system.diagnostics switch to the config and then in the code create a TraceSwitch with that name. Value is not read.

As in the repro https://github.com/aliostad/TraceSwitchDoesNotWork

Expected behavior

Reading value Error (1)

Actual behavior

Reading value Off (0) - perhaps just the default

Regression?

I tried netcoreapp3.1 and it was the same

Known Workarounds

None

Configuration

.NET 6.0 on mac, x64

Other information

No response

[dotnet-issue-labeler]

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

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

Issue Details

---

Description

Unlike what docs TraceSwitch value is not read from app.config.

I have created a repro here: https://github.com/aliostad/TraceSwitchDoesNotWork

Reproduction Steps

Add system.diagnostics switch to the config and then in the code create a TraceSwitch with that name. Value is not read.

As in the repro https://github.com/aliostad/TraceSwitchDoesNotWork

Expected behavior

Reading value Error (1)

Actual behavior

Reading value Off (0) - perhaps just the default

Regression?

I tried netcoreapp3.1 and it was the same

Known Workarounds

None

Configuration

.NET 6.0 on mac, x64

Other information

No response

Author:	aliostad
Assignees:	-
Labels:	area-System.Diagnostics, untriaged
Milestone:	-

[aliostad]

@noahfalk @tommcdon @TarekG

[noahfalk]

@maryamariyan

Sorry to be the bearer of bad news, this is a known limitation on .NET Core relative to .NET Framework even though the documentation of the change appears lacking. .NET Core stopped using app.config files in general and one of the repercussions is that this Trace configuration feature is no longer available. Hunting for docs I found a reference tucked away in a doc for migrating WinForms apps: https://docs.microsoft.com/en-us/dotnet/desktop/winforms/migration/?view=netdesktop-6.0#edit-appconfig and there are various 3rd party blog posts, but I think it would be more appropriate if we included it in our breaking changes docs as well as any tracing API docs that are talking about this capability. @maryamariyan I'd suggest we use this issue to track adding that missing documentation to help .NET developers be aware of this change.

Some potential options for working around the limitation:

1. Configure the TraceSwitch in code rather than in config files
2. Use the optional https://www.nuget.org/packages/System.Configuration.ConfigurationManager NuGet package to parse an app.config file, then write code that examines the parsed configuration and applies it to a TraceSwitch using the TraceSwitch APIs.
3. Migrate from the Trace* APIs to the ILogger APIs. ILogger does have integration with configuration via json and other mechanisms. More info here: https://docs.microsoft.com/en-us/aspnet/core/fundamentals/logging/?view=aspnetcore-6.0

[aliostad]

Hi @noahfalk

Thanks for the detailed and quick answer. Resolved quicker than I expected and a Happy Easter to you.

Yet, I hope you would not mind me feeling frustrated by the status of this - and a bit of a rant. When the ASP.NET team in .NET Core demolished what had been built before to enable a much richer application configuration, they really ignored the fact that app.config was way beyond an application configuration concern, it provided the whole framework with knobs. Whether these were worth keeping or not is a separate conversation but they should have been upfront in their design where these other capabilities should go or just dropped.

None of the options really appeal to me as a Library developer, not an application developer. Setting up configuration, is a responsibility of the application - and they are free to use whatever means they are comfortable with. Yet for the libraries and the framework, they should be oblivious to such diverse cases and instead rely on a consistent means of configuration
provided by the framework - otherwise they will also force their consumers upon their choice of configuration. This consistent configuration was being served by the app.config pretty well - although not my most favoured part of the framework.

CacheCow that has been deployed to production in dozens of places had defined a tracing switch so the consumers can turn on and off. Now for me back to drawing board to think of an alternative.

That was for me. But for others, please fix the docs to save them those many hours that I wasted trying so many different combinations.

Having said all of above, I might have missed something obvious and would be good to perhaps point out to me a reference or an example of how the library developers are meant to align to the new configuration.

Thanks
Ali

[KalleOlaviNiemitalo]

This was fixed in .NET 7.0 but the fix requires the application to call TraceConfiguration.Register explicitly. See:

• Support TraceSource to be initialized from the app.config file runtime#73087
• What's new in .NET 7 RC 1 core#7716 (comment) "System.Diagnostics.TraceSource can now be initialized from the app.config file"
• Breaking change: System.diagnostics entry in app.config

Although the TraceConfiguration.Register documentation mainly talks about TraceSource, the method adds a handler to the Switch.Initializing event, so it applies to TraceSwitch as well.

I think the documentation pages that were edited in #7979 should now be changed to mention TraceConfiguration.Register, and this issue should be kept open until that.