Understanding Where Code Is Run

I spend a great deal of time supporting Web Forms developers, especially new ones, on www.asp.net. The aspect of Web Forms development that causes the greatest confusion for new Web developers is not understanding where ASP.NET code actually executes.

A common scenario is this: A new Web developer has developed his first Web Form, and among the seemingly trivial things that he attempts is to display some feedback using the MessageBox.Show method. MessageBox.Show is a method used in Windows Forms applications to display a very simple message box. Depending on the developer, either of the following problems could occur:

The code does not compile, with the complaint that the name MessageBox does not exist in the current context.
The developer added a using line to the code and a reference to the Web site so that the System.Windows.Forms namespace (where MessageBox is located) is recognized and the code compiles, but it does not show a message box.

This example uses the MessageBox.Show method, but any number of other methods commonly used in Windows Forms applications just do not make sense in a Web Forms application. The following sidebar titled "What's Done Where?" addresses the underlying reason why a message box cannot be implemented directly in ASP.NET code.

The actions taking place and where those actions are taking place when a Web page is requested are shown in the following table.

Step	Action on the Server	Action on the Client
User requests page	Nothing	User types URL
ASP.NET builds HTML	C# code is executed and page is parsed	Nothing
User sees content	Nothing	Browser displays content

The important part of this sequence of events is that when the C# code is executed, it is executed on the server. Although the client and server can in some cases be the same machine, that is not normally the case. The new Web Forms developer who manages to get a Web Forms application that calls the MessageBox.Show method to compile might get a message box to appear, but it will not appear where the developer wants it to, on the client.

If the changes required for the page to run are made, and the page compiles, why would the message box not appear on the server where the code is executing? To understand the answer, you need to know a little about the way that Windows commonly runs services.

When you are developing an ASP.NET page, you will almost certainly be sitting right at the server as the page runs. However, when a real Web application is running, it is very likely that no one will be sitting at the server when the application is accessed. Often the machine running a Web page is at a remote site, often a site where a server or a portion of a server is rented with good, public Internet access. In these situations, having the Web server running and displaying messages is more than just not helpful, it can actually be detrimental to the function of the application. For instance, imagine that our Web Form with the call to the MessageBox.Show method actually did run and display a message box on the server. If no one is there to see it, what should happen to the application? MessageBox.Show is a blocking call. That means that it will wait, or block, in this case waiting for user input. Blocking is not good when you are running a Web server. However, more important than what would happen if the message box were to appear on the server is the fact that the message box will not appear on the server.

Why is this so? If our Web application is able to display a message box while server-side code is running, the message box is displayed on a virtual console that will not be visible, even to a user who might be sitting in front of the server. Windows services should not try to show any user interface; even if they do, any user interface will be "displayed" in an invisible virtual display rather than on the monitor at the server.

There are other implications of how Windows services run. For instance, every process running on a Windows-based machine runs under some user context. On the machine I am using to write this book, I am logged in as the user "XEON\Doug," which means that I am user Doug on a machine named XEON. When I do anything on the machine, Windows checks to ensure that XEON\Doug has rights to perform the task that I'm attempting.

So, how does it work when a Windows service wants to perform some operation on a file or other resource protected by Windows? To control Windows services, you can select Administrative Tools from the Control Panel, and then open Services. In the list of services, you can scroll down to the bottom of the list and double-click the World Wide Web service, which opens a dialog box with four tabs. On the Log On tab, you will see something like this.