Developer .NET UPDATE, December 10, 2002

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


Microsoft ASP.NET Connections & Visual Studio Connections

DevConnections Events and Windows & .NET Magazine Network


Microsoft ASP.NET Connections + Visual Studio Connections + SQL Server Magazine Connections equals the largest gathering of Microsoft product architects and independent IT gurus, delivering four days of hard-core drill down sessions that you will not find anywhere else. The Microsoft product team delivers over 35 cutting edge sessions on the latest product releases. In addition, you can choose from over 100 in-depth sessions presented by our world -class speakers, authors, and consultants who share real world solutions that will save you months of trial and error. Visit our expo hall to see the latest technology and have a chance to win a Harley Davidson among other cool give-always. After an intense day of sessions unwind at events like "Microsoft Unplugged" where no question is out of line or march in the Mardi Gras Parade to the House of Blues for a night to remember. Register early and get three power-packed events for the price of one. May 6 - 9, 2003 at the Hilton Riverside New Orleans. For more details, call 800-438-6720 or visit our web site.

December 10, 2002—In this issue:


  • Accessing the HTTP Context from a Web Service


  • The Microsoft Mobility Tour Is Coming Soon to a City Near You!
  • Get the New Windows & .NET Magazine Network Super CD/VIP!


  • Event: Integrate 2003


  • Create Database-Driven Web Sites

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

(contributed by Bill Sheldon, [email protected])


  • Last week, I showed you how to use an application's default Trace object to trace information in a Web service. This week, I continue to look at tracing within a Web service. I show you how the code in a Web service can access the HTTP context from which it might have been called. The phrase "might have been called" is important, and it's the point at which I want to start this week's discussion.

    Articles about designing Web services consistently report that Web services define an interface. Thus, the application that a Web service exposes can be consumed (i.e., used) without concern for the underlying implementation or, in some cases, without concern for how the information associated with a request is transmitted to the underlying application. In most cases, the articles present this concept from the standpoint of a client consuming a Web service. The rule is that a Web-service client can consume Web services running on any system with any implementation. The idea is that regardless of how the client calls the application, the Web service should respond in the same manner.

    As with any mathematical proof, the reverse of the client rule must also be true: The server implementation of a Web service can't depend on the calling framework. Because an HTTP request is a specific transport protocol that's independent of the application code, the application code shouldn't depend on this context. For this reason, the Trace object in the Web service is the object associated with Windows applications and not the object associated with the HTTP context. However, thanks to the openness of the Microsoft .NET Framework, objects and methods are available that let you access the HTTP context of the current request.

    When might you want access to the HTTP context of the current request? The first situation is when you're debugging a Web service. As I explained in my November 12 column "Tracing Down an Error," you can obtain automated timing information associated with the trace data when that timing information is handled in the context of an HTTP request. The ability to integrate trace and timing information can be useful in debugging Web services.

    The second situation in which you might want access to the HTTP context is when you want to check the security credentials that are embedded inside the HTTP request. Suppose you want to obtain the username of the person who's currently accessing a Web service and write that username to a trace log. In a Windows application, calling the System.Security.Principal.WindowsIdentity.GetCurrent().Name property gives you the username of the current user. Adding this call to your Web service provides the same result. However, when you use an HTTP request to call a Web service (as opposed to referencing a Web service locally within another project), the user is consistently ASPNET.

    So, for a Web service, you might need to check the user identity in two different locations. When the Web service is called as a component in a Windows application, the user identity will be retrieved from the Security.Principal.WindowsIdentity object. However, if this identity is ASPNET, you should then obtain the correct user identity by going through the HTTP context.

    To demonstrate the different ways to retrieve the user identity, change the security for your sample Web service. Under the Start menu on your Web server, select Programs, Administrative Tools, Internet Services Manager. Go to the virtual directory for your HelloWorld Web service, and right-click this directory to open its Properties dialog box. Select the Directory Security tab, and click Edit in the "Anonymous access and authentication control" section. In the dialog box that opens, make sure that the "Anonymous access" check box is clear, select the "Basic authentication" check box, then click OK. You can select the "Integrated Windows authentication" check box instead of the "Basic authentication" check box. However, I use Basic authentication for the following reasons:

    • Basic authentication always prompts me to enter credentials.
    • Basic authentication gives me access to the password.
    • Like a Web service, Basic authentication is compatible with any client.
    • Basic authentication forces me to disable debugging for the Web service (although tracing still works).

    After you modify the Web service, you need a way to access a request's HTTP context. To obtain this access, you use the System.Web.HttpContext class. Specifically, you use the Current property to obtain a copy of the current HttpContext object, which represents the HTTP information about the current HTTP request. From this object, you can reference the TraceContext object and all the system values associated with the HTTP request. Here's the HelloWorld Web method that includes code to access the HTTP context and use the TraceContext and HttpContext objects:

    public string HelloWorld()
       string strMyTrcVal;
       HttpContext objCurCtxt = System.Web.HttpContext.Current;
       // Let's use the TraceContext object.
       objCurCtxt.Trace.Warn("MyCat", "Hello World Starting");
       // Let's look at the default application's Trace object
       // at work.
       TextWriterTraceListener tfl = new 
       Trace.Write("Hello World Service:");
       Trace.WriteLine("MyCAT", "Process Click");
       strMyTrcVal = 
       strMyTrcVal = objCurCtxt.User.Identity.Name;
       strMyTrcVal = 
       // 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.
       // Write to the trace context that the method is finished.
       objCurCtxt.Trace.Warn("MyCat", "HelloWorld Complete");
       return "Hello World";

    This simple Web method has picked up quite a bit of code. Let's quickly review what this code is doing. After declaring the HelloWorld method, you use the Current property to obtain an instance of the HttpContext object, as I explained earlier. You then use the HttpContext object's Trace property to retrieve the TraceContext object for the current HTTP response. Next, you use TraceContext object's Warn method to write the message "Hello World Starting" under the MyCat category in the trace log. This first message is important because, in the background, it initializes the timers associated with each future trace message in the HTTP context.

    The next step is to open a custom listener for the application trace and write the static information. Specifically, you create an instance of the TextWriterTraceListener class to create a custom listener and direct the tracing information to the mytrace.log file. You then use the Write and WriteLine methods to write the static information to the log.

    After writing the static information, you need to add custom information from the application context. In this case, you write the machine name and username associated with the request. To obtain the user's name, you use the WindowsIdentity class, which represents the Windows user. After you create an instance of the class, you use the GetCurrent method to obtain a WindowsIdentity object that represents the current user.

    Next, you use the HttpContext object's User and Request properties to retrieve and write to the log more information from the HTTP context. The first piece of information is the identity of the user associated with the ASP.NET request. The second piece of information is part of the HTTP header, which when Basic authentication is enabled, will contain that user's password.

    After you've directed to the log the data you wanted to capture, you close the file and remove the trace listener. Finally, you make a last call to the HttpContext class's TraceContext object to specify that the method is finished. You'll notice that instead of making a call to Write method, I again called the Warn method.

    I'm not going to step you through running this code; previous columns have sufficiently covered how to review the associated trace information. I do, however, want to draw attention to the fact that the code uses two approaches to obtain the user's identity: the WindowsIdentity class's GetCurrent method (which obtains the user's identity from the Windows process) and the HttpContext object's User property (which obtains the user's identity from the HTTP context). If you want user-identity information for a production Web service, you should check both values and use the one that's appropriate for the way in which the Web service had actually been called. I want to make clear that you can't always rely on the presence of the HTTP context; when it's not present, you should rely on the identity of the current Windows process.

    Next week, I'll start discussing how to debug code that isn't executing locally. I'll explain the Web server requirements for remote debugging and show you how to step through the code.

    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]

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


  • Brought to you by Windows & .NET Magazine, this outstanding seven-city event will help support your growing mobile workforce. Industry guru Paul Thurrott discusses the coolest mobility hardware solutions around, demonstrates how to increase the productivity of your "road warriors" with the unique features of Windows XP and Office XP, and much more. There is no charge for these live events, but space is limited so register today!


  • Everyone can appreciate a bargain in today's economy. That's why we've introduced the Windows & .NET Magazine Super CD/VIP Web site. You get exclusive subscriber-only access to all our publications through our new VIP Web site. Plus, you get Super CDs delivered twice a year, and we'll even throw in a 1-year print subscription to the magazine! The Super CD/VIP is a $545 value for just $279. Subscribe today!



  • The Object Management Group (OMG) announces Integrate 2003, an event that will concentrate on the business and technical aspects of using many infrastructure standards to integrate applications. The infrastructure standards include OMG's infrastructure standard and other key industry standards, such as Web services, XML, Simple Object Access Protocol (SOAP), Visual C# .NET, Java, and Common Object Request Broker Architecture (CORBA). Sponsored by Rational Software's Power Pack Program, Integrate 2003 will be held January 28-29, 2003, in Burlingame, California. For more information about this event, go to

    (contributed by Sue Cooper, [email protected])


  • SoftLite released ScriptWorx.NET 5.1, a development environment that lets you use the Microsoft .NET Framework to quickly design Web applications, services, and databases. Suitable for new and advanced developers, ScriptWorx.NET supports key technologies, including ASP.NET, XML, Visual Basic .NET, Visual C# .NET, and Simple Object Access Protocol (SOAP). The new release offers a fully integrated XML environment, live XML transformations, an XML inspector, a collapsible overview of XML documents, and a SOAP debugger. A one-user license costs $399. Contact SoftLite 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.