This chapter is from the book
This chapter is from the book
This chapter is from the book
ASP .NET Projects
Now we get to the point where Visual Studio .NET really shines in comparison to previous versions. Previously, to develop a web application with Visual Studio tools, you had to jump between Visual Interdev, FrontPage, and VB, depending on the type of web application you were building. You used Visual Interdev to build client-side web applications, FrontPage for static pages, and VB to develop web classes and server-side components. Each tool had its strengths and weaknesses. All that is history with Visual Studio.NET. There are no longer separate tools required to develop web applications. The process for developing a server-side web application is now as close as it gets to the process for developing a standard Windows application. Let's create a simple application to demonstrate what we mean.
Before we begin, let's make sure we have all of the requirements in place to create a web application. If you did a full install of Visual Studio.NET Professional or higher you should be all right, but let's make sure.
-
You need to have Internet Information Server (IIS) 5.0 installed. This is installed with Windows 2000 or XP Pro. If you are running Windows NT 4.0, you should check the version. Visual Studio should have updated it if it detected that it was out of date.
-
The IIS service must be started on Port 80.
-
Make sure some other product did not install another web server, such as Apache. On Windows XP, you will not receive an error when two services try to use the same port (80). The first service to start gets the port. On WinNT 4 and 2000, you will receive a message in the event log if another application tries to start on a port already in use. If another product is using Port 80, you will have to stop that service to use IIS. Also, make sure you change the service's startup method to manual.
-
IIS needs to be updated with Microsoft ASP.NET files (ASPX) extensions. Again the Visual Studio install should have installed these. To check, open the Management Console (right-click on My Computer and select Manage), expand the Internet Information Services node, expand Web Sites, right-click on Default Web Site, and select Properties. Select the Home Directory tab and then click the Configuration… button on the lower half of the form. You should see something like that shown in Figure 3.9.
Figure 3.9. ISAPI mappings for ASP.NET applications.
)
Figure 3.9Notice all the references to .NET. If you do not see any of these you may have to reconfigure your machine. The Visual Studio Installer should do this for you.
Once you are sure all of the prerequisites are met, you can create your project. Close any projects that are open. Select New Project and when the dialog opens select ASP.NET Web Application. Change the name of the project to ADOBook03-03. and click OK. The first thing different you will notice is that Visual Studio contacts the web site. This is because Visual Studio keeps the project on the IIS server. If this is your local machine the default path is C:\InetPub\WWWRoot\ADOBook03-03. If the web site is on a server, then the files are located there. The Project Explorer should look like Figure 3.10, with the References node expanded.
)
Figure 3.10. A new ASP.NET project.
Things to notice:
References— Notice the reference to System.Web. This library contains all of the classes for building a web application.
ADOBook03-03.vsdisco— This is the Web Services discovery document. This document is used for Universal Description, Discovery and Integration (UDDI) directory services. These services help users find Web Services and provide a standard for their discovery. It is like a search engine for Web Services.
Web.config— This document contains application configuration information, in a similar manner to an ini file.
If you open the vsdisco or web.config files, you will see that they are Extensible Markup Language (XML) files. That is after all what Web Services are all about. The saying for .NET is "If you can't tell, assume it's XML!"
Now comes the real neat part. Let's add a button to our new Web Form. Roll out the toolbox. Now, instead of the Windows controls, we see Web Form controls. Drag and drop a button onto the form. By default, the form uses absolute positioning for elements, meaning elements are fixed and cannot move around by themselves when the user resizes the browser window. You can use flow positioning as well. With this mode the elements will repaginate when the user resizes the window. Since we are designing forms, we will stay with absolute positioning. If the user's browser window is too small to contain the full form, scroll bars will appear to let the user expose the rest of the form.
Now let's also add a label to inform our user of the application's purpose. Drop a label control on the form. Change the text property of the label to read Say Hello World Application. Change the button's text property to read Say Hello. Position the controls as shown in Figure 3.11.
)
Figure 3.11. The top of the Web Form.
TIP
When designing Web Forms, keep the targeted users in mind. If you have the ability to require a minimum screen resolution (800x600 for example) then you should design your form with this in mind. If you will have no control over your user's machine. then you should design your form to a minimum standard of 640*480 so anyone will have a positive experience. Studies have shown that the user's experience counts most for the success of any application, no matter how elegant the underlying code is.
Create a Web Form. Change the pageLayout property of this form to FlowLayout. Now you can type directly on the page. In fact, you have all of the design features of FrontPage right in the IDE! Drop down the style list and select Heading 1. Type Hello World directly on the page. Also, drop another button onto the page. Change its text to Back. Just for fun, click on the HTML tab at the bottom of the design window. You will see that it is pretty normal HTML. ASP.NET applications by default generate standard HTML so the forms will run on any browser.
In WebForm1, double-click the button. A code window will open and a click event procedure will appear. In the body of the click event, enter this code:
Me.Response.Redirect("WebForm2.aspx")
Now do the same thing with WebForm2 except enter WebForm1 in the line of code. Now comes the good part. Click the Run button. As expected the program compiles, but instead of running as a Windows application a browser window opens and the WebForm1 appears. Pull down the View menu and select Source. Look at the HTML. It is very basic HTML. Click the Say Hello button. WebForm2 appears. Click the Go Back button and WebForm1 reappears. To end the application, close the browser window. All of the processing occurs on the server so the page will render properly in any browser. Just to try this out, I accessed the page from a Linux box I have running the KDE X-Windows environment. It uses a browser called Konquerer. (It's supposed to be a sly dig on Explorer, I think.) It's not Netscape, Internet Explorer (IE), or any well-known browser. The application worked just fine.