Developer .NET UPDATE, December 3, 2002

Developer .NET UPDATE—brought to you by Windows & .NET Magazine Network.


DevConnections Events and Windows & .NET Magazine Network

SPONSOR: DevConnections Events and Windows & .NET Magazine Network

Now you can receive timely information about technical education conferences and seminars from DevConnections Events and Windows & .NET Magazine Network. Stay up to date on the latest details about Microsoft ASP.NET Connections, Visual Studio .NET Connections, SQL Server Magazine LIVE!, Windows & .NET Magazine LIVE!, and XML Web Services Connections. Subscribe for FREE by sending a blank email to: [email protected]

December 3, 2002—In this issue:


  • Using Trace Class Listeners


  • Planning on Getting Certified? Make Sure to Pick Up Our New eBook!
  • Sample Our Security Administrator Newsletter!


  • Add Imaging to Your Applications

See this section for a list of ways to contact us.

(contributed by Bill Sheldon, [email protected])


  • As I described last week, when you work with a Web service, you're dealing with an application that's a hybrid of a pure Windows application and an ASP.NET application. As a result, the default ASP.NET trace information logs contain only a small amount of trace information and the default trace display doesn't include any information associated with custom trace statements. This week, I want to show you how to capture and store information from custom trace statements.

    The code inside a Web service needs to run like any other Windows application. As a result, the code runs in an application framework, as opposed to automatically running in an HTTP request context. Thus, custom trace statements that you place in application code behave differently in a Web service. Instead of automatically including the messages from such statements in the trace.axd page, the default application Trace object includes a Listeners collection that, by default, sends information to the Visual Studio .NET Output window. The Listeners collection lets you send trace-related information to other locations. You can send output to a file or an event log. Let's look at how you send this information to a file.

    To send trace information to a file, you must add logic to the trace statements. For example, the HelloWorld Web method might look like

    public string HelloWorld()
       TextWriterTraceListener tfl = new 
       Trace.Write("Hello World Service:");
       Trace.WriteLine("MyCAT", "Process Click");
    // Force the trace information to be written.
    // Remove this object from the Listeners collection so that 
    // you can dispose of the object.
    // Close the file now that you're done with it.
       return "Hello World";

    As you can see, the trace logic's complexity has grown significantly. After declaring the HelloWorld method, you must create an instance of the Microsoft .NET Framework's TextWriterTraceListener class object. This class object lets you easily pass trace messages to a file. When you create this instance, you need to provide the name of the file to which you want to pass messages. In theory, you can provide the filename without providing a full path. However, the class then attempts to use the \Windows\System folder as the default path, which causes a permission error. So, in reality, you need to specify the file's full pathname, which in this case is D:\\mytrace.log.

    After you've created an instance of the TextWriterTraceListener class object (i.e., a "listener"), you need to add the listener to the Listeners collection associated with the application's Trace object. As part of the Listeners collection, the Trace object automatically sends output to your listener. Thus, when you make calls to the Trace object's Write and WriteLine methods, the Trace object sends the output to not only the Output display in Visual Studio .NET but also to mytrace.log.

    The Trace object has an application or global scope, so when you add your listener to the collection, the listener is part of the collection for everyone using the HelloWorld method, not just the current request. As a result, the HelloWorld method code has several statements to restore the Trace object to its original state. The first such statement is Trace.Flush(). Calling the Flush method forces the Common Language Runtime (CLR) environment to write the trace data to the disk. This call is important when you're working with Web services because the Web service call is often completed and the objects discarded while the trace data is suspended in memory. To avoid this situation, always use the Flush method just before using the Remove and Close methods.

    The Remove method in the Trace.Listeners.Remove(tfl) statement removes the listener that you added to the Listeners collection. Because the listener you created has only limited applicability and Microsoft IIS is a multithreaded environment, using the Remove method is important. If you don't remove the listener, other IIS threads will fail when attempting to write to the mytrace.log file that the listener opens. This situation illustrates a crucial point to remember when you use a Trace object with an output file: Because the file isn't closed between Trace commands (e.g., Trace.Write), the OS permits only one thread to proceed at a time. This single threading means that only a single request is processed at a time. The result is that you should only use the Trace object with an output file in development and testing environments.

    The Close method in the tfl.Close() statement closes the mytrace.log file. As with any file I/O operations, using the Close method should be your last file operation. If you were to close the file before removing the listener, for example, you would run the risk of an error. Think of the code that lies between the listener's creation and the ending Close statement as a transaction in which you want everything associated with the listener completed within the confines of that transaction. In keeping with transaction rules, you want to write code that starts and completes the transaction with minimal delay.

    With the additional trace-logic code in place, you're ready to run the Web service. When it runs, you'll see the mytrace.log file created. After the call to the Flush method, the trace data that you wanted to capture will be written to the file. You can now have others test your Web service and capture key debugging information.

    As I mentioned earlier, you can use a file or an event log to capture trace comments. Capturing trace data in an event log is difficult when you're working with a Web service because of the permissions associated with access. On a Web server, you're typically running under ASP.NET's worker thread, which has limited permissions. These permissions don't include access to those portions of the registry associated with event logs. As a result, attempting to access an event log causes an error. Event logs work great for Windows applications that run locally, but when you have a Web service that you access through IIS permissions, problems arise. Thus, although the object supports working with an event log, for a Web service, you need to assign special registry permissions, which potentially opens a security hole.

    To work around the Trace object's limitations, you can use the TraceContext object, which is available by default to Web applications. Although Web services run as application code, if you call them from an ASP.NET application, you can access the ASP.NET environment context. After you have the request context, you can access information related to the request. I'll discuss this process in detail next week. In the meantime, you can find more information about the listeners at this URL.

    (brought to you by Windows & .NET Magazine and its partners)


  • "The Insider's Guide to IT Certification" eBook is hot off the presses and contains everything you need to know to help you save time and money while preparing for certification exams from Microsoft, Cisco Systems, and CompTIA and have a successful career in IT. Get your copy of the Insider's Guide today!


  • Security breaches and viruses can happen to your enterprise. But there are steps you can take to prevent disaster, like subscribing to Security Administrator, the print newsletter from the experts at Windows & .NET Magazine. Every issue shows you how to protect your systems with informative, in-depth articles, timely tips, and practical advice. Don't just take our word for it—get a sample issue today!

    (contributed by Sue Cooper, [email protected])


  • Atalasoft announced ImgX Controls 6.2, a suite of controls that lets Visual Basic (VB) and Microsoft .NET developers add imaging functionality to their applications. Basic imaging functions include capturing, scanning, and printing images. The software reads and writes to most graphics file formats. It uses a low-level C++ imaging library, providing fast image processing with an ActiveX front end. ImgX Controls 6.2 is .NET ready, with two .NET components that wrap around and extend the functionality of the ImgX6 COM component. You can use the controls in any environment that supports ActiveX, including Delphi, Visual FoxPro, VB, Visual C++, and Visual Studio .NET. Pricing is $299 for the full version and $149 for the Lite version. Contact Atalasoft at [email protected].

    Here's how to reach us with your comments and questions:

    Hide comments


    • Allowed HTML tags: <em> <strong> <blockquote> <br> <p>

    Plain text

    • No HTML tags allowed.
    • Web page addresses and e-mail addresses turn into links automatically.
    • Lines and paragraphs break automatically.