다음을 통해 공유

A Tracing Primer - Part II (C) [Mike Rousos]

  • 아티클

In my introduction to tracing (https://blogs.msdn.com/bclteam/archive/2005/03/15/396431.aspx), I outlined the basics of how to use TraceSources, TraceListeners, and SourceSwitches to trace the flow of an application. I also covered how to configure Whidbey tracing with a configuration file.

In this series of three follow-up articles, I plan to discuss the use of TraceFilters, custom listeners, and a recent change we made to where config-defined listeners create their output files.

This short final section (part C) will focus on how relative paths in tracing config files are understood.

A Final Note (What Relative Paths in Config Files are Relative To)

Although this does not relate to filters or custom listeners like the rest of the second installment of my tracing primer, it’s an interesting bit of information that may be useful to people who use our tracing system, so I thought I would include it here.

 

Up until a couple of weeks ago, a relative path in a config file (specifically, in the initializeData attribute of a listener declaration) would point to a file relative to the working directory when the listener was created.

 

This was a problem, though, for many ASP.Net applications that were using System.Diagnostics tracing because the working directory would (by default) be the .NET framework directory since this is where the aspnet_wp.exe assembly, which runs these apps, lives. This is not a desirable place for tracing output to go by default.

 

So, we’ve made a change such that relative paths in configuration files will now refer to paths relative to the config file’s location. For many apps, this won’t change anything, but for ASP.Net apps, it will keep the tracing output in a reasonable location.

 

The one scenario that this will disrupt will be the scenario in which listeners are defined in the machine.config file for winforms and console apps to use. This is not a place where we suggest defining listeners, but up until this change it worked. The problem now (as you may have guessed) is that such listeners will now create output files relative to the .NET framework directory's config path. This is almost as bad as the .NET framework directory itself.

 

If your app faces this problem, here are suggested work arounds:

  • The correct solution is to define your listeners in a more local way (in the individual apps' config files, instead of globally creating listeners in Machine.Config).
  • If you need a temporary work around that allows the listener definitions to remain in Machine.Config, you can try creating local app.config files that have nearly empty System.Diagnostics sections. Technically, the config file path that listeners are created relative to is the path of the last loaded config file (the farthest down the chain of config files). This means if you have an app.config file that simply defines the Trace.autoflush attribute (set it to false if you want to keep default behavior), all the listeners defined in the machine.config file will create their output files relative to this app.config file's path.

Let me just reiterate, though, that we intend for ASP.Net users to define listeners in their web.config files and for the output files to be easily found. We did not expect that users would need to create listeners in the machine.config file. That's why changing the paths to be relative to the config file rather than the working directory makes sense. For most (non-ASP.Net) applications, the updated behavior will not change anything.

 

Closing

 

I hope that everyone found this information to be interesting. If people enjoy this sort of design decision information, I'll continue to post similar items as we make interesting decisions with regard to System.Diagnostics tracing design.

 

Also, this is the final installment of my tracing primer (for the time being). So, for now, let me just say that I hope it has helped anyone with questions about how to use System.Diagnostics tracing in their applications and let me encourage you to send any further questions you may have regarding these APIs to the BCL team's public feedback alias (BCLPub@microsoft.com). Also, if there are tracing topics not covered in one of these four posts that you would really like to see me blog on, let me know. If I get enough requests for interesting material, I may put together a part III down the road. Thanks!

Comments

  • Anonymous
    September 20, 2005
    Did you consider making the relative paths work both ways, depending on the app?

    if (HttpContext.Current == null){
    relativePath = WorkingDirectory;
    }
    else {
    relativePath = ConfigFileDirectory
    }
  • Anonymous
    September 14, 2006
    WPF (Avalon) uses the .Net tracing system to provide some diagnostics about what’s going on inside your WPF application.  It’s not at all an exhaustive set of traces, and in fact it’s still pretty rudimentary.  But frequently it’s enough to help out when
  • Anonymous
    September 15, 2006
    WPF (Avalon) uses the .Net tracing system to provide some diagnostics about what’s going on inside your WPF application.  It’s not at all an exhaustive set of traces, and in fact it’s still pretty rudimentary.  But frequently it’s enough to help out when
  • Anonymous
    March 15, 2007
    We have an applciation (Bought from another company) that has a very good logging system, and during