1

I am using a third party tool which internally adds trace messages using the following code:

System.Diagnostics.Trace.WriteLineIf(
    new System.Diagnostics.TraceSwitch("Switch", "").TraceInfo, message);

In this scenario, it appears that I must add the switch to my app.config file to get the trace messages to appear:

<system.diagnostics>
  <switches>
    <add name="Switch" value="3" />
  </switches>
</system.diagnostics>

Since not all of my users are granted administrator rights to make changes in the Program Files directory this becomes an issue.

Is it possible to set the TraceSwitch programmatically and allow the third party tool to write the trace messages?

mreith
  • 299
  • 4
  • 15

1 Answers1

1

Yes to first part of question. Probably no to second part, since the third-party is creating a new TraceSwtich on each call to WriteLineIf. In my opinion, it seems the third-party control has a failed implementation because 1) it should allow you to change the "switch" programmatically through a property, method, or function, and 2) it is reading the config file on every trace statement.

AMissico
  • 21,470
  • 7
  • 78
  • 106
  • 1
    @AMissico: Thanks, that's what I expected but I was hoping that there was some trick of which I was unaware. Time to add a service ticket... – mreith Oct 06 '09 at 16:17
  • Just thought of something. How about removing the default trace listener then adding you own. Then you can specify all trace messages in the config file and filter out what you want in the new listener. Actually, this is a good idea and would be easy to implement. – AMissico Oct 06 '09 at 19:17
  • @AMissico: I have already implemented my own listener but the third party tool will not write the trace messages to any listener without the app.config modification. – mreith Oct 06 '09 at 21:47
  • @mreith: Yes, but I am assuming you will be deploying the modified app.config (to allow for all messages) with your application, and the user will have some way to enable/disable your listener and set the message filter. I can't see any other way to work around this limitation of the third-party tool. – AMissico Oct 06 '09 at 22:28
  • @mreith: Just like I am assuming you have TRACE defined in your Release build. – AMissico Oct 06 '09 at 22:38
  • @AMissico: I had not considered deploying the modified app.config file considering it too inefficient. The third party tool would attempt to write significant numbers of messages. If I can't get the third party tool to create a fix then only users who can get access to admin mode will be able to modify the app.config file to see the trace. I think that's the best solution for the situation. Thanks for reminding me to set TRACE in Release. I would have forgotten that for sure. – mreith Oct 07 '09 at 05:00
  • @mreith: "TRACE in Release" is set by default. Why not put the config in an alternate location? For example, if not found in appliation folder then look in user's folder where they do have permission. I believe you can load a configuration file from anywhere. I never used it but OpenExeConfiguration() looks interesting. – AMissico Oct 07 '09 at 06:04
  • @mreith: "would attempt to write significant numbers of messages", the tool is going to try and write these messages regardless if you have a config file or not. It is the TRACE constant that makes the difference. That is why I stated their implementation was poor to read the switch on every call. They should read the switch on startup, default to a value if no config is found, and give you a property to set the switch. Therefore, creating a config, setting the switch to all, and replacing the default trace listener with your listener will not affect performance. – AMissico Oct 07 '09 at 06:10
  • @mreith: You really need to get the vendor to fix their product. – AMissico Oct 07 '09 at 06:10
  • 1
    It turns out that the vendor did have an undocumented method to do this - I just had to ask. – mreith Oct 07 '09 at 23:54