Partager via

Troubleshooting WCF In Production Environments

  • Article

WCF is such a nice framework, and its diagnostics capabilities are really comprehensive. Really, I only have two (pseudo-)issues with diagnostics so far:

  • Configuring diagnostics is pretty difficult to do (lots of XML editing involved)
  • Reading trace and message logs is hard. By default, it's in XML, so it's 'human-readable', but there's just so much of it that it becomes nigh-unreadable in reality

In both cases, the answer is a tool, and such tools actually exist: The Service Configuration Editor (SvcConfigEditor.exe) addresses the first point, and the Service Trace Viewer (SvcTraceViewer.exe) the second. Both are part of the SDK and can be found in "C:\Program Files\Microsoft SDKs\Windows\v6.0\Bin" (or whereever your SDK is installed).

The only problem with this is that in production (or staging or test) environments, the SDK isn't typically installed, and nor should it be. Alas, this also means that those two very useful tools aren't available either, which makes troubleshooting on a production client or server much harder.

After a couple of days of manually copying configuration and trace files back and forth between my laptop and the test server I was troubleshooting, the obvious solution hit me. It's so simple that you probably already know this trick, and if that's the case, I apologize for having made you read this far.

Both the Service Configuration Editor and Service Trace Viewer tools are .NET applications, and since they don't have any fancy dependencies (apart from .NET 3.0), you can deploy them via xcopy. While I don't particularly recommend that you copy them to your production servers or random clients, you can copy them to a USB stick that you can carry around.

Whenever you need to use these tools, but don't have the SDK installed on a machine, you can just plug the USB drive in the machine and run the tools from there.

There you have it: You may have figured this out long ago, but for those of you who are as slow as me, I hope this little trick can save you some time.

Comments

  • Anonymous
    October 02, 2007
    If you have read access for logs and (heaven forbid) write access to the config file on your server, both applications will happily read the files off the network location.

  • Anonymous
    October 02, 2007
    Good point. In the case I just experienced, however, I didn't have network access from my developer machine to the server in question, so that wasn't an option. In my experience, that's not too uncommon a case, so it's nice to know that if you can't bring the log files to you, you can bring the tools to the log files :)

  • Anonymous
    October 02, 2007
    Good hint/idea. An alternative to a USB stick is of course a net drive. Many server configurations (e.g. blade servers) does not have a USB interface.

  • Anonymous
    October 02, 2007
    Another good point. You can also burn the tools on a CD or DVD. The Service Configuration Editor is too large (1960 kB), but the Service Trace Viewer even fits nicely on a 1.44 MB floppy disk :) You could even carry it around on your phone and transfer the files via BlueTooth, but I guess blade servers don't have BlueTooth either :) The main point here is that these tools are very portable, so you don't need to install anything to use them.

  • Anonymous
    October 06, 2007
    The comment has been removed

  • Anonymous
    October 06, 2007
    The comment has been removed

  • Anonymous
    April 19, 2008
    This is a digest of WCF Security resources I was collecting for some time. Drop me a comment in case

  • Anonymous
    September 22, 2008
    The comment has been removed

  • Anonymous
    September 22, 2008
    Hi Pingala Which error are you getting?

  • Anonymous
    September 23, 2008
    The comment has been removed

  • Anonymous
    September 23, 2008
    If you perform a Live search after 'EventType clr20r3' you will see there's a lot of grief about that message. I've never seen it before, but it seems to be related to attempts at using CLR types that are not available on the installed framework. Could you, perchance, be trying to use a 3.5 SvcConfigEditor.exe on 3.0?