System.Diagnostics.TraceSource doesn't read configuration from App.config in .NET Core?

[jemiller0]

The following code outputs "Hello, world!" as a trace message to the console when in a .NET Framework console application. When the same code is used in a .NET Core console application, it outputs nothing.

Program.cs

using System.Diagnostics;

namespace ConsoleApp5
{
    class Program
    {
        private readonly static TraceSource traceSource = new TraceSource("ConsoleApp5", SourceLevels.All);

        static void Main(string[] args)
        {
            traceSource.TraceEvent(TraceEventType.Information, 0, "Hello, world!");
        }
    }
}

App.config

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
  <system.diagnostics>
    <trace autoflush="true">
      <listeners>
        <add name="consoleTraceListener" />
        <add name="textWriterTraceListener" />
      </listeners>
    </trace>
    <sharedListeners>
      <add name="consoleTraceListener" type="System.Diagnostics.ConsoleTraceListener" traceOutputOptions="DateTime,ThreadId" />
      <add name="textWriterTraceListener" type="System.Diagnostics.TextWriterTraceListener" traceOutputOptions="DateTime,ThreadId" initializeData="Trace.log" />
    </sharedListeners>
    <sources>
      <source name="ConsoleApp5" switchValue="Verbose">
        <listeners>
          <add name="consoleTraceListener" />
          <add name="textWriterTraceListener" />
        </listeners>
      </source>
    </sources>
  </system.diagnostics>
</configuration>

Also, I found that if I try to read a connection string using System.Configuration.ConfigurationManager and I have the system.diagnostics section in the App.config, I receive the following error. I'm assuming that .NET Core doesn't have a machine.config where the system.diagnostics section would normally be defined?

Unhandled Exception: System.Configuration.ConfigurationErrorsException: Configuration system failed to initialize ---> System.Configuration.ConfigurationErrorsException: Unrecognized configuration section system.diagnostics. (C:\Users\jemiller\Documents\Visual Studio 2017\Projects\Library2\LibraryConsoleApplication\bin\Debug\netcoreapp2.0\LibraryConsoleApplication.dll.config line 6)
   at System.Configuration.ConfigurationSchemaErrors.ThrowIfErrors(Boolean ignoreLocal)
   at System.Configuration.BaseConfigurationRecord.ThrowIfParseErrors(ConfigurationSchemaErrors schemaErrors)
   at System.Configuration.ClientConfigurationSystem.EnsureInit(String configKey)
   --- End of inner exception stack trace ---
   at System.Configuration.ClientConfigurationSystem.EnsureInit(String configKey)
   at System.Configuration.ClientConfigurationSystem.PrepareClientConfigSystem(String sectionName)
   at System.Configuration.ClientConfigurationSystem.System.Configuration.Internal.IInternalConfigSystem.GetSection(String sectionName)
   at System.Configuration.ConfigurationManager.GetSection(String sectionName)
   at System.Configuration.ConfigurationManager.get_ConnectionStrings()
   at LibraryLibrary.LibraryContext..ctor(String name) in C:\Users\jemiller\Documents\Visual Studio 2017\Projects\Library2\LibraryLibrary\LibraryContext.cs:line 43
   at LibraryLibrary.LibraryContext..ctor() in C:\Users\jemiller\Documents\Visual Studio 2017\Projects\Library2\LibraryLibrary\LibraryContext.cs:line 39
   at LibraryConsoleApplication.Program.Main(String[] args) in C:\Users\jemiller\Documents\Visual Studio 2017\Projects\Library2\LibraryConsoleApplication\Program.cs:line 13

Is there I way I could specify the section similar to the following to get it to work? That is how it is defined in machine.config for .NET Framework.

  <configSections>
    <section name="system.diagnostics" type="System.Diagnostics.SystemDiagnosticsSection, System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"/>
  </configSections>

Is there some other way in .NET Core to specify that configuration settings for system.diagnostics?

[jemiller0]

I looked at the source code for TraceSource in .NET Core. It appears that the code does not read configuration settings from App.config. In addition, it looks like .NET Core doesn't even have a ConsoleTraceListener. So, it looks like you can't even log to the console using TraceSource even if you programmatically configured it.

[danmoseley]

@brianrob could you please answer the questions above about trace source?

When TraceSource was written, we did not have configuration API's. Now we do, and TraceSource could presumably be changed to read app.config, but @brianrob note this would presumably mean pulling System.Configuration.ConfigurationManager library into the shared framework, as it is not currently in it.

[jemiller0]

I can't even get it to work by programmatically adding a TextWriterTraceListener. The following code works with .NET Framework, but, does nothing with .NET Core.

using System.Diagnostics;

namespace ConsoleApp5
{
    class Program
    {
        private readonly static TraceSource traceSource = new TraceSource("ConsoleApp5", SourceLevels.All);

        static void Main(string[] args)
        {
            Trace.AutoFlush = true;
            traceSource.Listeners.Add(new TextWriterTraceListener("Trace.log"));
            traceSource.TraceEvent(TraceEventType.Information, 0, "Hello, world!");
        }
    }
}

As far as I can tell, TraceSource is just flat out broken and unusable in .NET Core.

[danmoseley]

OK, @brianrob or @vancem need to give guidance...

[jemiller0]

So, why is this being closed? TraceSource is basically completely non-usable as it stands now.

[danmoseley]

Because the Close button is too close to the Comment button :)

[MikeDempseyFL]

I'm no expert on tracing but I am currently trying to figure out how to turn on network tracing for sockets - replacing the app.config entries for system.diagnostics with whatever is required to have the same effect in .NET Core.

While looking into this I found that TextWriterTraceListener did not seem to work as expected, but by using DefaultTraceListner I could write the output I expected.

In your example you would simply replace: traceSource.Listeners.Add(new TextWriterTraceListener("Trace.log")); with: traceSource.Listeners.Add(new DefaultTraceListener()); DefaultTraceListener dtl = (DefaultTraceListener) traceSource.Listeners["Default"]; dtl.LogFileName ="Trace.log";

To avoid writing to the debug output window twice add the following before this code: traceSource.Listeners.Clear();

My guess is that this is not really what you want to do - you are just playing around with a very simplified version of tracing as a means of trying to figure out how this works in Core. If anyone can describe how to configure network tracing in Core I'm sure there would be a lot of folks interested.

[jemiller0]

Do you know if that applies to all instances of TraceSource? If yes, then, maybe it would be possible to use. Otherwise, you need the configuration file because chances are you have many instances of TraceSource and configuring them programmatically isn't feasible.

[MikeDempseyFL]

In my own test I simply used Trace.Listeners.Add() rather than creating my own source so the issue is generic from that point of view.

[wilson0x4d]

@danmosemsft @brianrob probably this is asked a million times for a million things, but, any idea when this bug might get picked up? It's a pretty powerful and often undervalued facility that is mostly useless from an operational standpoint because "configuration management" means changing code and redeploying (or we continue sticking to .NET Framework for these features.)

[jemiller0]

ConfigurationManager is there now. However, it has been lobotomized and only supports things like ConnectionStrings. And App.config doesn't work in certain contexts, like if you have a unit test assembly, it is not read. System.Diagnostics.TraceSource doesn't use App.config in .NET Core. So, you have to programmatically configure every single instance you have, making it for practical purposes unusable.

[danmoseley]

@jeremykuhne also

[brianrob]

From dotnet/runtime#16332: In general, we are not expanding support for TraceSource. However, if there is someone who is interested in contributing support for System.Configuration, I think that is OK.

I am marking this up-for-grabs. Next step is to propose a design.

[JeremyKuhne]

If/when somebody picks this up feel free to contact me about how to make the relevant changes to System.Configuration. It isn't very easy to navigate.

[igalnassi]

I have been using TraceSource very successfully in .Net Framework with the initial configuration done through app.config and support for runtime updates on the log levels / listeners etc. Now, I have to write my own logic to handle initial configuration from a config file? This seems wrong.

Is there a logger that can be used for both .Net Framework and .Net Core that would work the same way and have ways to configure initial state from a config file?

[vancem]

• @jorive as he has picked up diagnostics from @brianrob

[MarcoDorantes]

I have been using TraceSource very successfully in .Net Framework with the initial configuration done through app.config and support for runtime updates on the log levels / listeners etc. Now, I have to write my own logic to handle initial configuration from a config file? This seems wrong.

Is there a logger that can be used for both .Net Framework and .Net Core that would work the same way and have ways to configure initial state from a config file?

Hi, @igalnassi . For what it worth, and for your information, using .NET Core 3.0, the configuration at app.config section still does not have effect on System.Diagnostics.Trace class methods (like WriteLine). But, now I am able to manually add, for example, a System.Diagnostics.TextWriterTraceListener, to the Trace.Listeners collection and now the Trace.WriteLine method worked again as traditionally expected.

Best regards,

[jemiller0]

It would be great if Microsoft would add this functionality back in. The new logging API that requires dependency injection and other third party libraries is a monstrosity. You should not have to rely on third party software for something as fundamental as logging. Also, you shouldn't have to rely on overly complicated design patterns such as dependency injection. TraceSource was straight forward and easy to use. The new way isn't. Maybe it's fine for an ASP.NET application, where it originated. It is not fine for a simple console application.

[jemiller0]

I should say, maybe I would be fine with configuring it programmatically. That is, if you could configure it globally. The way it stands now, you can't. You have to configure each TraceSource instance, which typically are going to be all over the place. For practical purposes, it makes it unusable. Unfortunately, Microsoft doesn't care. They would rather just push you into using the new piece of garbage.

[igalnassi]

For what it’s worth, we migrated to NLog and its support to load from Config files without restarting has helped tremendously. It’s performance is among the best as well. Very happy with our choice.

On Mon, Oct 28, 2019 at 15:01 Jon Miller notifications@github.com wrote:

I should say, maybe I would be fine with configuring it programmatically. That is, if you could configure it globally. The way it stands now, you can't. You have to configure each TraceSource instance, which typically are going to be all over the place. For practical purposes, it makes it unusable. Unfortunately, Microsoft doesn't care. They would rather just push you into using the new piece of garbage.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/dotnet/corefx/issues/24829?email_source=notifications&email_token=ADVNZV4QIZYVW6CVGUQGVLTQQ4ZGXA5CNFSM4EAOHWDKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOECOAV7A#issuecomment-547097340, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADVNZV7AVVNQ5OJFHQL54GLQQ4ZGXANCNFSM4EAOHWDA .

[jbe2277]

I agree with @jemiller0 's proposal to allow configuring it programmatically. This would allow us to use TraceSource when the TraceSource instance is not available to the application.

Maybe you find my Wiki page interesting: Logging with .NET Standard 2.0. It describes how to use TraceSource and to expose the TraceSource instance. This way it can be used by .NET Core and it might be combined with 3rd party logger like NLog.

[obiwanjacobi]

I feel TraceSource should be removed until it works. It is very misleading to put in code that compiles but does not work as expected. It wastes the time of the developer. Not sure if there are more cases like these - better to include only stuff that actually works. You could put it in a prerelease/experimental package, but it must be very clear what the deal is.

[jemiller0]

@obiwanjacobi I agree and disagree. The current implementation is brain dead and I think it should be fixed. However, I'm currently using the current brain dead solution with hacks. So, I would prefer that it stay in there and not be removed. It is better to just fix it.

[stasberkov]

We are planning to move our asp.net mvc 4.6 code to .net core. In our code we really like logging via TraceSource. It would be really great if you fix this for .net core. Late I found this: https://github.com/dotnet/runtime/blob/master/src/libraries/System.Diagnostics.DiagnosticSource/src/DiagnosticSourceUsersGuide.md

Is DiagnosticSource a replacement of TraceSource?

[MSACATS]

I just wanted to chime in as well and say what a loss this is. We used System.Diagnostics.Trace a lot, and it is pretty much the remaining issue in our Framework to Core migration, and a big one.

With System.Diagnostics.Trace:

• internal components can expose trace output
• activity can be correlated. for example, we can start an "operation", and that operation will flow through to other components that are tracing
• components can expose multiple discrete trace sources
• components can access discrete trace options. for example, we can have a trace switch for whether or not to trace raw HTTP request and response data to our vendors
  • this is separate from "verbose", "info", "warning", etc.
  • as a concrete example, each vendor integration has its own trace source. but they share a low-level HTTP component. That HTTP component has a switch for whether or not to trace the raw request/response data (which it will emit as 'verbose'). The raw data tracing comes out of each vendor's own trace source (each with its own current output level), hence we can specifically control the raw HTTP request/response data tracing, even though each vendor's output will be coming out of its own trace source (tagged with the correlation id of the overall operation!)
  • thus if only one of those vendors is wired up to trace at "Verbose" level, only that vendor will have such output
• different trace outputs can be routed to different locations (e.g. event log, file, database)
• all of this can be configured via the config file

ILogger can also be set up with the config file, but doesn't provide anything close to this. For example having a component expose multiple sources, or having specific tracing options (like the HTTP request/response data option). And the scoping seems to be per-log source, rather than carrying through across multiple components. The biggest issue is it can only be used via dependency injection, which is not always practical - e.g. how do you trace out of an extension method? Logging always seemed to be one of those grey areas for dependency injection, but in any case Logging is not quite the same as Tracing.

DiagnosticSource is a bit closer (any component can emit a diagnostic source), but it's pretty onerous to use and to attach listeners. Everything would have to be done in code, and basically we'll have to take all the informal Tracing, and put object wrappers on everything, it seems, in order for anything to make sense: It's more of an event logging framework as far as I can tell. Hence its similarity to EventSource.

I tried wiring things up in code, but that still leaves TraceSwitches - I can configure the trace listeners and whatnot in Startup but there's no way I can see to set a trace switch, they used to read from the configuration to set their runtime value

[JeremyWard33]

I just spent a couple hours trying to figure this out. Why is this not well advertised? Developers are going to beat their heads on this like I did and that's really bad business for y'all.

[TishSerg]

Spent hours trying to figure out what I'm doing wrong with App.config in .NET 6... Oh, that's it. Ok, .NET Framework, your shot.

[jemiller0]

The .NET Core geniuses decided config files are bad and got rid of them

[wilson0x4d]

... this is what happens when every few years a group of new developers appear which don't have adequate exposure to technology, declare it bad, then start removing/replacing things that worked perfectly fine.

after 30+ years of programming i've learned that nothing survives, not even good things. sad, but true. everything everyone has worked on in .NET Core these past few years will also, eventually, be undone by some future generation of programmers that don't have adequate exposure to technology, will declare it bad, then start removing/replacing things that work perfectly fine.

nothing fundamentally changed, but it was still changed. between the lack of backward compatibility (FROM MICROSOFT NO LESS!) and perpetual bugs being introduced to their development tools i've decided to retire early. make hay in the sun, watch the cattle graze, etc. i'll come back if we're lucky enough to experience another Carrington event and actually need to rebuild the world... but as it is, there are better things to invest precious lifespan into than other people's messes.

Loosely related, https://github.com/wilson0x4d/diagnostics#bootstrapping-systemdiagnostics-in-net-core

... but it is not maintained, and not the most elegant code I've ever written, but if someone is determined to use app.config files and the classic logging framework then you may find some joy there.

such a shame. from DI to logging and everything in between +poof+ gone. what began as a xplat initiative turned into a rewrite from the ground up.

[jemiller0]

@wilson0x4d What you said is exactly how I feel about it. Looking forward to retirement. I have often theorized that all the original developers at Microsoft who created .NET quit for higher paying jobs elsewhere. Then Microsoft was left with people who didn't know the existing code base who decided to re-write everything. That might be fine if the result was something that worked better, but, that's not the case. Web development in particular has taken a turn for the worse. It was better 20 years ago.

[danmoseley]

@dotnet/area-system-diagnostics-tracing can we better document this?

[ghost]

Tagging subscribers to this area: @dotnet/area-system-diagnostics-tracesource See info in area-owners.md if you want to be subscribed.

Issue Details

---

The following code outputs "Hello, world!" as a trace message to the console when in a .NET Framework console application. When the same code is used in a .NET Core console application, it outputs nothing. Program.cs ```csharp using System.Diagnostics; namespace ConsoleApp5 { class Program { private readonly static TraceSource traceSource = new TraceSource("ConsoleApp5", SourceLevels.All); static void Main(string[] args) { traceSource.TraceEvent(TraceEventType.Information, 0, "Hello, world!"); } } } ``` App.config ```xml ``` Also, I found that if I try to read a connection string using System.Configuration.ConfigurationManager and I have the system.diagnostics section in the App.config, I receive the following error. I'm assuming that .NET Core doesn't have a machine.config where the system.diagnostics section would normally be defined? ``` Unhandled Exception: System.Configuration.ConfigurationErrorsException: Configuration system failed to initialize ---> System.Configuration.ConfigurationErrorsException: Unrecognized configuration section system.diagnostics. (C:\Users\jemiller\Documents\Visual Studio 2017\Projects\Library2\LibraryConsoleApplication\bin\Debug\netcoreapp2.0\LibraryConsoleApplication.dll.config line 6) at System.Configuration.ConfigurationSchemaErrors.ThrowIfErrors(Boolean ignoreLocal) at System.Configuration.BaseConfigurationRecord.ThrowIfParseErrors(ConfigurationSchemaErrors schemaErrors) at System.Configuration.ClientConfigurationSystem.EnsureInit(String configKey) --- End of inner exception stack trace --- at System.Configuration.ClientConfigurationSystem.EnsureInit(String configKey) at System.Configuration.ClientConfigurationSystem.PrepareClientConfigSystem(String sectionName) at System.Configuration.ClientConfigurationSystem.System.Configuration.Internal.IInternalConfigSystem.GetSection(String sectionName) at System.Configuration.ConfigurationManager.GetSection(String sectionName) at System.Configuration.ConfigurationManager.get_ConnectionStrings() at LibraryLibrary.LibraryContext..ctor(String name) in C:\Users\jemiller\Documents\Visual Studio 2017\Projects\Library2\LibraryLibrary\LibraryContext.cs:line 43 at LibraryLibrary.LibraryContext..ctor() in C:\Users\jemiller\Documents\Visual Studio 2017\Projects\Library2\LibraryLibrary\LibraryContext.cs:line 39 at LibraryConsoleApplication.Program.Main(String[] args) in C:\Users\jemiller\Documents\Visual Studio 2017\Projects\Library2\LibraryConsoleApplication\Program.cs:line 13 ``` Is there I way I could specify the section similar to the following to get it to work? That is how it is defined in machine.config for .NET Framework. ```xml

``` Is there some other way in .NET Core to specify that configuration settings for system.diagnostics?

Author:	jemiller0
Assignees:	-
Labels:	`bug`, `area-System.Diagnostics.Tracing`, `up-for-grabs`, `area-System.Diagnostics.TraceSource`
Milestone:	Future

[noahfalk]

I think this got directed to the wrong devs, we want https://github.com/orgs/dotnet/teams/area-system-diagnostics-tracesource for this. Thanks @tarekgh for helping clarify ownership here and I noticed @jkotas fixed the label, appreciate it!

[RussKie]

Just to note that the inability to configure TraceSwitchs from app.config affects dotnet/winforms, and likely quite a few Windows Forms apps...

[MSACATS]

Just to note that the inability to configure TraceSwitchs from app.config affects dotnet/winforms, and likely quite a few Windows Forms apps...

To clarify, is there any way to configure a TraceSwitch now?

I tried wiring things up in code, but that still leaves TraceSwitches - I can configure the trace listeners and whatnot in Startup but there's no way I can see to set a trace switch, they used to read from the configuration to set their runtime value

https://github.com/dotnet/runtime/issues/23937#issuecomment-746629241

[MSACATS]

Just to note that the inability to configure TraceSwitchs from app.config affects dotnet/winforms, and likely quite a few Windows Forms apps...

Indeed - https://github.com/dotnet/runtime/discussions/68753

[Brain2000]

Wait, so you're telling me that we have win32 forms in .net core 6, but no tracing? Let me repeat that again, are you telling me there isn't any way to do tracing in .net core??? Someone needs to lay off the crack.

[MarcoDorantes]

Wait, so you're telling me that we have win32 forms in .net core 6, but no tracing? Let me repeat that again, are you telling me there isn't any way to do tracing in .net core??? Someone needs to lay off the crack.

I am unaware of ".net core 6". Nowadays, I am aware of ".NET 6.0". Also, I felt very frustrated at the time by some functional/behavioral breaking changes to System.Diagnostics of .NET Core 1.0 to 3.0. Nevertheless, for my case, there were alternatives —since then— with minor application-level changes targeting .NET Core 3.1. Now, after trying to understand the evolutionary design decisions to logging along the way to the current .NET 6.0, I admit there have been regular improvements to System.Diagnostics. Besides, and most importantly, now I better understand the provider model for logging: I am giving it a chance.

[jemiller0]

Not everyone wants to jump through hoops and use dependency injection. The new setup is ridiculous. Maybe it is fine for an ASP.NET web app, which from what I know is where it originated, but, it is ridiculous in other contexts. Besides that, not everyone wants infinite configurability. They want something simple that is included with the core platform that works out of the box and doesn't require a ton of other open source/third party dependencies. I think Microsoft did a really poor job on this. If you want to have the other one in addition to this, then fine, but, this should have been kept if for no other reason for backwards compatibility. I have to wonder about the entire approach that Microsoft took in creating the multi-platform version. Breaking changes all over the place. Dropping Web Forms was ridiculous as well.

[MarcoDorantes]

Last time I check, the entire .NET Framework 4.8 is fully supported and still works as usual (including all System.Diagnostics exact behavior as always). The design decision to target a given runtime is, for the most part, on the hands of the designers of a given application-level solution.

[jemiller0]

Yes, and 4.8 is basically frozen except for bug fixes. It doesn't take a rocket scientist to see what the problem is. Rewrite all your applications because Microsoft opted for piss poor support of major components such as Web Forms.

[MarcoDorantes]

The software designers at Microsoft have taken their design decisions. I assume they are taking good care of their business. Time will tell if that become the case.

On the other hand, I am in charge of my design decisions for my own business. All business solutions of mine are up and running and supporting the businesses of my customers. Their businesses are shield from work-in-progress by any of my providers (including Microsoft). The evolution of those business solutions, of course, includes research on the evidence for completeness of any runtime or API by any provider, way before touching any feature branch (including possible deprecations of any runtime or API to better alternatives).

[MSACATS]

Marco, is this a fair summary of your suggestions?

1. stick on .NET Framework 4.8 forever
2. rewrite all tracing simply because there's no way to configure TraceSource, TraceSwitch

and that as long as Microsoft makes money, there is no reason for them to work out this oversight?

Being honest with yourself, do these seem like particularly constructive suggestions?

"It does not benefit you to fight the people who fight for more."

[jkotas]

oversight?

TraceSource is a very slow tracing mechanism. It was an intentional decision to remove it as the tracing mechanism for the core .NET runtime libraries, not an oversight.

.NET runtime libraries such as networking or sockets have been unified on System.Diagnostics.EventSource as the one and only built-in high-performance tracing mechanism.

rewrite all tracing simply because there's no way to configure TraceSource, TraceSwitch

TraceSource can be configured programmatically as shown above.

[MSACATS]

It was an intentional decision to remove it as the tracing mechanism for the core .NET runtime libraries, not an oversight.

We're not talking about configuring the core libraries, we're talking about our own code.* You're truly arguing that the inability to configure TraceSource via the configuration files is simply for our own good because the performance is bad? Then why is it still present at all and not removed entirely?

*Edit: actually, I misspoke. For example https://github.com/dotnet/runtime/issues/23937#issuecomment-1116474842

TraceSource can be configured programmatically as shown above.

Cool, what about TraceSwitch? TraceSource and TraceSwitch are closely related.

[jkotas]

You're truly arguing that the inability to configure TraceSource via the configuration files is simply for our own good

I am not arguing about this part.

[RussKie]

.NET runtime libraries such as networking or sockets have been unified on System.Diagnostics.EventSource as the one and only built-in high-performance tracing mechanism.

Optimising for some libraries we've broken other stacks, e.g. Windows Forms. It's no longer possible enable the tracing without recompiling an app.

[jemiller0]

You can use someone's third-party add on to try to do it. Or, literally have to programmatically configure every single of TraceSource you have manually. There is this thing called compatibility. Microsoft forgot what that was when they brought in new developers and rewrote everything from scratch.

[stephentoub]

NET runtime libraries such as networking or sockets have been unified on System.Diagnostics.EventSource

Optimising for some libraries we've broken other stacks, e.g. Windows Forms

How does networking using EventSource break Windows Forms?

[RussKie]

@stephentoub I'm talking about inability to configure tracing via app.config in .NET.