Beginning AP.NET 1.0 with C#

John Wiley & Sons

Chapter One

ASP.NET is a new and powerful technology for creating dynamic web pages. It's a convergence of two major Microsoft technologies, Active Server Pages (ASP) and .NET. ASP is a relative old-timer on the web computing circuit and has provided a sturdy, powerful, and effective way of creating dynamic web pages for five years or so now. .NET is the new kid on the block and is a whole suite of technologies designed by Microsoft with the aim of revolutionizing the way in which programming development is conducted in the future, and the way companies carry out business. As a conjunction of the two, ASP.NET is a way of creating dynamic web pages while making use of the innovations present in .NET.

The first important thing to know about ASP.NET is that you don't need any ASP skills to be able to learn it. In fact all you need is a little HTML knowledge for building your own web pages. Knowing any ASP could in some ways be a disadvantage, because you might have to 'unlearn' some of the principles you previously held to be true. ASP.NET is a more powerful technology than its old namesake. Not only does it allow you to build dynamic web pages, but it also tailors the output in HTML to whatever browser you're using, and comes with a great set of reusable, predefined, and ready to use controls for use in your ASP.NET projects, which reduce the amount of code you have to write, so you can be more productive while programming.

So what can you do with ASP.NET? It might be easier to list what you can't, as that is arguably shorter! One of the most eye-catching things is the way you can use any programming language based in .NET, such as C#, VB .NET, or JScript .NET, to create your web applications. Within these applications, ASP.NET enables you to customize pages for a particular user, makes it much simpler now to keep track of a particular user's details as they move around, and makes storing information to a database or self-describing XML document faster and easier. You can alter the layout of the page using a visual IDE rather than having to figure out positioning within code, and even alter the contents of files on your machine (if you have the correct permissions). You can also use bits and pieces of other applications without downloading the whole application: for example, you can access a zip code verifier that is exposed by another web site, without having to download the whole of that application, or giving your users the impression that they've left your site (we'll talk more about this in the Web Services chapter later on). Basically, with ASP.NET the applications that you create are only limited by your imagination.

In this first chapter we'll be mainly concerned with ASP.NET's installation process. We'll start with a quick introduction to the world of web servers, dynamic web pages, and a little bit about what ASP.NET is, but what we really aim to achieve is to get you up and running a fully functional web server, with a fully functional ASP.NET installation. By the end of the chapter you'll have created a short ASP.NET test page to check that both the web server and ASP.NET are both working as intended. We'll also have a look at some of the most common pitfalls encountered, just in case things don't go as planned!

We will cover the following topics:

Static Web Pages Dynamic Web Pages An overview of the different technologies for creating dynamic web pages, including ASP.NET Installing Internet Information Services (IIS) Installing the .NET Framework Testing and troubleshooting your installation

What is a Static Web Page?

If you surf around the Internet today, you'll see that there are lots of static web pages out there. What do we mean by a static web page? Essentially, it's a page whose content consists of some HTML code that was typed directly into a text editor and saved as an .htm or .html file. Thus, the author of the page has already determined the exact content of the page, in HTML, at some time before any user visits the page.

Static web pages are often quite easy to spot: sometimes you can pick them out by just looking at the content of the page. The content (text, images, hyperlinks, etc.) and appearance of a static web page is always the same - regardless of who visits the page, or when they visit, or how they arrive at the page, or any other factors.

For example, suppose we create a page called welcome.htm for our web site, by writing some simple HTML like this:

Welcome

Whenever any client comes to our site to view this page, it will look like this. The content of the page was determined before the request was made - at the time the Webmaster saved the .htm file to disk:

How are Static Web Pages Served?

OK, so let's think for a moment about how a static, pure-HTML page finds its way onto a client browser:

1. A web author writes a page composed of pure HTML, and saves it within an .htm file on the server. 2. Sometime later, a user types a page request into their browser, and the request is passed from the browser to the web server. 3. The web server locates the .htm page and converts it to an HTML stream. 4. The web server sends the HTML stream back across the network to the browser. 5. The browser processes the HTML and displays the page.

Static, pure-HTML files like Welcome.htm make perfectly serviceable web pages. We can even spruce up the presentation and usability of such pages by adding more HTML to alter the fonts and colors. However, there's only so much we can achieve by writing pure HTML, precisely because the content is completely determined before the page is ever requested.

The Limitations of Static Web Pages

For example, suppose we want to enhance our Welcome page - so that it displays the current time or a special message that is personalized for each user. These are simple ambitions, but they are impossible to achieve using HTML alone. If you're not convinced, try writing a piece of HTML for a web page that displays the current time, like this:

As you type in the HTML, you'll soon realize the problem - you know that the user will request the page sometime, but you don't know what the time will be when they do so! Hard-coding the time into your HTML will result in a page that always claims that the time is the same (and will almost always display the wrong time).

In other words, you're trying to write pure HTML for a web page that displays the time - but you can't be sure of the exact time that the web page should display until the time the page is requested. It can't be done using HTML alone.

Also, HTML offers no features for personalizing your web pages: each web page that is served is the same for every user. There's also no security with HTML: the code is there for everybody to view, and there's nothing to stop you from copying somebody else's HTML code and using it in your own web page. Static pages might be very fast, as quick as copying a small file over a network, but they are quite limited without any dynamic features.

Since we can't create our page by saving our hard-coded HTML into a file before the page is requested, what we need is a way to generate the HTML after the page is requested. There are two ways of doing this. We'll look at them both shortly, but before we go any further we need to make sure everybody is up to speed on the terminology we've introduced here.

What is a Web Server?

A web server is a piece of software that manages web pages and makes them available to 'client' browsers - via a local network or over the Internet. In the case of the Internet, the web server and browser are usually on two different machines, possibly many miles apart. However, in a more local situation we might set up a machine that runs the web server software, and then use a browser on the same machine to look at its web pages. It makes no difference whether you access a remote web server (that is, a web server on a different machine from your browser application) or a local one (web server and browser on the same machine), since the web server's function - to make web pages available to all - remains unchanged. It might well be that you are the only person with access to your web server on your own machine, as would be case if you were running a web server from your home machine. Nevertheless, the principles remain the same.

While there are many web servers available - the commonest ones being Apache, Internet Information Services (or IIS, for short) and Iplanet's Enterprise server - we're only going to talk about one in this book: Microsoft's IIS. This is because it is the only web server that will run ASP.NET. The web server comes as part of the installation for both Windows 2000 and Windows XP. IIS version 5.0 comes with Windows 2000 and IIS version 5.1 with Windows XP; however, there is very little to distinguish the two, and we shall treat them in this chapter as the same product. We'll look at how you go about installing IIS shortly, but first, let's take a look at its role in helping to create dynamic web pages.

How are Dynamic Web Pages Served?

To fully understand the nature of dynamic web pages, we first need to look at the limitations of what you can and can't do with a static web page.

Two Ways of Providing Dynamic Web Page Content

Even though, in this book, we're only going to be creating dynamic web pages using one of two very different methods, we need to be aware of the differences between these two different ways of doing things, as the underlying principles for both feature heavily throughout the book.

Client-Side Dynamic Web Pages

In the client-side model, modules (or plug-ins) attached to the browser do all the work of creating dynamic pages. The HTML code is typically sent to the browser, along with a separate file containing a set of instructions, which is referenced from within the HTML page. However, it is also quite common to find these instructions intermingled with the HTML code. The browser then uses them to generate pure HTML for the page when the user requests the page - in other words, the page is generated dynamically on request. This produces an HTML page, which is displayed in the browser.

So in this model our set of five steps now becomes six:

1. A web author writes a set of instructions for creating HTML, and saves it within an .htm file. The author also writes a set of instructions in a different language. This might be contained within the .htm file, or within a separate file. 2. Sometime later, a user types a page request into their browser, and the request is passed from the browser to the web server. 3. The web server locates the .htm page, and may also have to locate a second file that contains the instructions. 4. The web server sends both the newly created HTML stream and instructions back across the network to the browser. 5. A module within the browser processes the instructions and returns the results as HTML within the .htm page - only one page is returned, even if two were requested. 6. The HTML is then processed by the browser, which displays the page.

Client-side technologies have fallen out of favor in recent times, as they take a long time to download, especially if you have to download more than one file. A second drawback is that each browser interprets client-side scripting code in different ways, so you have no way of guaranteeing that if Internet Explorer understands them, Netscape Navigator or Opera will also be able to process them. Other major drawbacks are that it is a problem to write client-side code that uses server-side resources such as databases because it is interpreted at client-side. Also, client-side scripting code isn't secure and can be easily viewed with the View Source Code option on any browser, which might also be undesirable, and may compromise the security of the web site.

Server-Side Dynamic Web Pages

With the server-side model, the HTML source is sent to the web server with an intermingled set of instructions. Again this set of instructions will be used to generate HTML for the page at the time the user requests the page. Once again, the page is generated dynamically upon request. However, there is a subtle twist regarding where the processing of instructions is done:

1. A web author writes a set of instructions for creating HTML, and saves these instructions within a file. 2. Sometime later, a user types a page request into their browser, and the request is passed from the browser to the web server. 3. The web server locates the file of instructions. 4. The web server follows the instructions in order to create a stream of HTML. 5. The web server sends the newly created HTML stream back across the network to the browser. 6. The browser processes the HTML and displays the page.

The twist is that all the processing is done on the server, before the page is sent back to the browser. One of the key advantages this has over the client-side model is that only the HTML is actually sent to the browser. This means that our page's original code is hidden away on the server, and that we can safely assume that most browsers should be able to at least have a go at displaying the generated HTML. ASP.NET, as you might have gathered, does its processing on the server-side.

While both processes for serving a dynamic web page add only a single step to the process for serving a static web page (Step 5 on the client or Step 4 on the server) this single step is crucial. In this step the HTML that defines the web page is not generated until after the web page has been requested. For example, we can use either technique to write a set of instructions for creating a page that displays the current time:

Welcome