Moving from Visual Basic to ASP.NET

 

Scott Mitchell

August 2003

Applies to:
    Microsoft® ASP.NET
    Microsoft® Visual Basic®

Summary: Learn the similarities and differences between Web application development using ASP.NET and classic desktop application development. This article is aimed toward Visual Basic 6.0 developers who are interested in getting started with creating ASP.NET Web applications, and examines the differences between creating desktop applications with Visual Basic 6.0 and creating ASP.NET Web applications with Visual Basic .NET. (15 printed pages)

Download ASPNETCrashCourse.msi.

Contents

Introduction
Getting Started with ASP.NET
Creating Our First ASP.NET Web Page
Important Differences Between Web Applications and Desktop Applications
Sending a Value From One Web Form to Another
Conclusion

Introduction

Before .NET came along, there were many distinct and fundamental differences between creating classic ASP Web applications and building desktop Microsoft® Windows® applications with Microsoft Visual Basic® 6.0. For starters, Visual Basic application user interfaces were designed with drag-and-drop GUI tools in Microsoft Visual Studio®, whereas the user interfaces for ASP Web applications were created by manually adding the HTML markup to generate the correct interface. Also, ASP Web pages contained script code with a mix of HTML markup and source code, whereas Visual Basic applications dealt with classes, modules, and other structured and object-oriented programming constructs.

With the advent of .NET, classic ASP evolved to ASP.NET. Various features of ASP.NET make creating ASP.NET Web pages fairly similar to creating an individual form in a Visual Basic application. Despite these similarities, there are still some fundamental differences in creating Web and desktop applications, due to their delivery mediums.

In this article we will first look at what you need to do in order to get started creating ASP.NET Web applications (developers who have already started working with ASP.NET may choose to skip this section). Then, we will examine those features of ASP.NET that make creating ASP.NET Web applications akin to creating Windows desktop applications. We'll also see some quick examples of creating ASP.NET Web pages using Visual Studio .NET to illustrate the striking similarity in creating Web applications and desktop applications. There are some fundamental differences between creating Web and desktop applications that we will also examine. Finally, we'll look at a common Visual Basic task—passing information between Forms—and examine how to accomplish this in an ASP.NET Web application.

Getting Started with ASP.NET

Before we can begin to examine creating an ASP.NET Web page, you will first need a computer that can serve ASP.NET Web pages. It needs to run Microsoft Windows 2000, Microsoft Windows XP Professional, or Microsoft Windows Server™ 2003. If you do not have access to such a machine, you can always employ the services of a Web hosting company. For information on Web hosts that support ASP.NET, visit the ISPs with ASP.NET Support forum at the ASP.NET Forums.

If you elect to use your own computer to serve the ASP.NET Web pages, you need to install two software components:

• Microsoft Internet Information Service (IIS) 5.0 or greater
• The .NET Framework

IIS is Microsoft's Web server that ships free with server versions of Windows. IIS 6.0 ships standard with Windows Server 2003, while IIS 5.0 ships on Windows 2000 and Windows XP Professional. In order to determine if IIS is installed on your Windows 2000, Windows XP Professional, or Windows 2003 Server machine, open the Control Panel, go to Add/Remove Programs, and click on the Add/Remove Windows Components button. This will display the dialog box shown in Figure 1. If you see the Internet Information Services checkbox checked, IIS is installed; otherwise, check the checkbox and click the Next button to install IIS.

Figure 1. Ensure IIS is installed by viewing the Windows Components dialog box.

For more information on installing IIS, refer to the following official guides on Microsoft.com.

• Installing IIS on Windows 2003
• Installing IIS on Windows XP
• Installing IIS on Windows 2000

In addition to installing the IIS Web server, you must also install the .NET Framework Redistributable on the Web server. At of the time of this writing, the .NET Framework is at version 1.1, and can be downloaded from Microsoft .NET Framework Version 1.1 Redistributable Package. The .NET Framework contains the framework of classes needed to execute .NET applications on the Web server. Since ASP.NET Web applications are .NET applications and utilize the many classes in the .NET Framework, it is essential that the .NET Framework Redistributable be installed on the Web server.

Note While you can install the Web server and the .NET Framework in any order, it is recommended that you install the Web server first. This is because when installing the .NET Framework second, the Web server's configuration settings are updated so that the Web server can start serving ASP.NET Web pages. If you install the .NET Framework first, the Web server won't serve ASP.NET Web pages. This can easily be fixed by running the aspnet_regiis.exe file. More information can be found at 4GuysFromRolla.com : ASP FAQS : ASP.NET.

Creating Our First ASP.NET Web Page

While ASP.NET Web pages—like Visual Basic applications—can be created with any text editor, using tools like Visual Studio .NET can make the process much easier. For developing ASP.NET Web pages you should have the latest version of Visual Studio .NET installed on the computer from where you will be developing the ASP.NET Web pages. There exist other development editors for ASP.NET, such as the ASP.NET Web Matrix, but Visual Studio .NET offers a design interface that most closely resembles the design interface for Visual Basic 6.0.

Let's create a simple ASP.NET Web page to demonstrate just how similar creating an ASP.NET application is to creating a classic Windows desktop application. Start by firing up Visual Studio .NET and creating a new Visual Basic ASP.NET Web Application project. Next, in the Location drop-down list, specify the URL where you want your ASP.NET application to exist. If you are planning on serving the ASP.NET Web pages from the same computer you are developing on, leave the URL as https://localhost/ and choose a project name, entering https://localhost/ProjectName. If you are hosting your ASP.NET Web application on a remote Web server, enter the URL or IP address to the Web server and the project name like http://WebServerURLorIP/ProjectName. Figure 2 shows a screenshot of the Visual Studio .NET New Project dialog box for creating a new Visual Basic ASP.NET Web application at https://localhost/ASPNETCrashCourse.

Figure 2. Create a new Visual Basic ASP.NET Web application.

Upon clicking the OK button, Visual Studio .NET will create the new Web application. This involves creating the directory specified in the Location drop-down list, adding some files, and updating the Web server's configuration to denote that the newly created directory should be an IIS application.

An ASP.NET Web application is composed of a number of ASP.NET Web pages. Each Web page is a distinct file with the .aspx file extension. ASP.NET Web pages, to an ASP.NET Web application, are what individual Forms are to a Visual Basic 6.0 application. That is, an ASP.NET Web page represents an interface with which the Web visitor interacts. Like a Visual Basic Form, each ASP.NET Web page is composed of two distinct parts:

• A graphical user interface
• A class whose code responds to events raised by the controls in the user interface

Oftentimes ASP.NET Web pages are referred to as Web Forms. The controls that can be added to an ASP.NET Web page's user interface are known as Web controls.

Upon creating a new ASP.NET Web application, a default Web Form is created, WebForm1.aspx. Figure 3 shows a screenshot of Visual Studio .NET after creating a new ASP.NET Web application project.

Figure 3. Visual Studio .NET, after creating a new ASP.NET Web application project

Take a moment to examine Figure 3 in more detail. Note that it's currently showing the Designer for WebForm1.aspx. The Designer provides a WYSIWYG view of the ASP.NET Web page, showing you what users visiting the Web page will see. To add Web controls to the ASP.NET Web page, simply drag them from the Toolbox and drop them onto the Designer.

Since ASP.NET Web pages are Web pages, after all, in addition to the Web controls they contain HTML markup. To view the HTML markup for the ASP.NET Web page, simply click the HTML button, which is located next to the Design button at the bottom left-hand corner of the Designer. Therefore, you can work on the ASP.NET Web page's user interface either via the WYSIWYG Designer, or by directly modifying the Web page's HTML via the HTML view.

To get acquainted with Visual Studio .NET and to better understand the process of creating an ASP.NET Web application, let's add some Web controls to WebForm1.aspx. Specifically, let's create an ASP.NET Web page that functions as a simple financial calculator; one that computes the amount of interest someone will realize on an investment, given a starting principal, an interest rate, and the investment duration.

To accomplish this, we will need to add a number of Label and TextBox Web controls, as well as a Button Web control. The Label Web controls, like in Visual Basic 6, display either static or dynamic text content. To add a Label Web control, simply drag and drop the Label Web control from the Toolbox onto the Designer. Next, click on the Label Web control to load its properties into the Properties pane. Here you can set its Text property to the value of the text you want to display and its ID property to some unique value. Similarly, you can add a TextBox Web control to the Designer.

Figure 4 shows a screenshot of the Designer after all of the needed Label and TextBox Web controls have been added. Note that there is a TextBox Web control for each user input that needs to be collected. When adding these Web controls, you should set the ID property of each Web control to a meaningful value. As in Visual Basic, the ID property serves as a unique identifier and is how the Web control is referenced programmatically in the ASP.NET Web page's source code. For this exercise, give the TextBox Web controls IDs of StartValue, Rate, and Duration.

Figure 4. The Designer after the appropriate label and TextBox Web controls have been added

In addition to the Label and TextBox Web controls shown in Figure 4, we need to add two more Web controls. The first one is a Label Web control that will display the results of the financial calculation. Place this Label Web control near the bottom of the page; clear out its Text property and assign its ID property the value, Results. Finally, we'll need a Button Web control. This Web control will display a button that the user will click upon entering the data. Set this Button Web control's Text property to Display Future Investment Value. After adding these two Web controls your screen should look similar to the screenshot in Figure 5.

Figure 5. The Designer, after the final two Web controls have been added

At this point we have finished the user interface design, and we're ready to start writing the code. Specifically, we want to perform the financial calculation when the Button Web control is clicked and display the results in the Results Label. Just as in a Visual Basic 6 Form, you can add an event handler for the Button Web control's Click event by simply double-clicking the Button in the Designer.

Upon creating the event handler for the Button Web control's Click event, you will be taken directly to the source code portion of the ASP.NET Web page, which will have the new event handler (shown in Figure 6). The source code portion for an ASP.NET Web page resides in a separate file, named WebForm1.aspx.vb.

Figure 6. The Click event handler has been automatically added to the ASP.NET Web page's source code portion.

All that remains left to do is to write the code to compute the future value of the investment, and to display this value in the Results Label. The following shows the complete code for the Click event handler. As a Visual Basic developer, this code should be fairly straightforward.

Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As
  System.EventArgs) Handles Button1.Click
        ' Compute the future value of the investment, which is the
        ' principal plus the interest garnered over time
        ' EQUATION: Value = Principal * e^(Rate/12 * Duration)

        Dim value As Double
        Dim beginningWith As Double = StartValue.Text
        Dim interestRate As Double = Rate.Text
        Dim investmentTime As Double = Duration.Text

        value = beginningWith * Math.Exp((interestRate / 100) *
          investmentTime / 12)

        'Assign the resulting value to the Results Label
        Results.Text = "The investment, after " & investmentTime & "
          months," & _
                       " will be worth: " & FormatCurrency(value)
End Sub

To test out the ASP.NET Web page, simply go to the Debug menu and choose Start (or hit F5). This will compile the ASP.NET Web page's source code and launch a Web browser, loading in the specified start page (WebForm1.aspx is the default start page). You should see a browser window similar to Figure 7. If you enter values into the textboxes and then click the button, you'll see a result displayed beneath the entry form, as shown in Figure 8.

Figure 7. WebForm1.aspx, when first visited

Figure 8. WebForm1.aspx, after information has been entered and the "Display Future Investment Value" button has been clicked.

Important Differences Between Web Applications and Desktop Applications

While the many similarities between creating Web and desktop applications make the process of building ASP.NET applications a more familiar one for Visual Basic developers, there are a few subtle, yet profound differences that must be understood. The most basic difference between Web applications and desktop applications is the medium they are delivered on.

Desktop applications are run directly on the user's computer as a self-contained entity. There is no physical separation between the application's user interface and the processing of the user's input. Furthermore, the state of the application is self-contained. That is, if the user needs to fill out several forms worth of data, each form can easily know about and access the values from previous forms.

With Web applications, however, these same rules do not apply. With a Web application, the source code that processes a user's input resides on the Web server, while the user interface is sent to the user's computer and displayed on her Web browser. Therefore, there is no direct connection between the user-interface and the Web application's code.

Take the financial calculator application—when a Web visitor requests the ASP.NET Web page, the ASP.NET Web page returns HTML markup dependent upon the page's user interface and the code that is executed in the page's source code portion. The user's Web browser renders this received HTML markup into a graphical user interface on the user's computer. At this point there is no direct connection between the ASP.NET Web page that produced that HTML markup and the user's Web browser.

From his computer, our user will enter data into the various textboxes and then click the "Display Future Investment Value" button. Upon clicking this button, the user's Web browser makes a request back to the same ASP.NET Web page, sending the value the user entered into the assorted textboxes along with other information. From this information, the ASP.NET Web page can determine that the user clicked the button, and therefore fires the Button Web control's Click event, causing the Click event handler to execute. This Click event handler, as we saw earlier, computes the final investment value and displays this value in the Results Label. This new display is sent back to the user's browser as HTML markup, and the user now sees the Web page as before, but with the future investment value displayed near the bottom.

Realize that the disconnected, stateless nature of the Internet places some restrictions on the functionality Web applications can provide. For example, imagine that you were designing an application that prompted the user for their ZIP code, among other things. With Visual Basic it would be very easy to add a TextBox control and to trap each keystroke made to that control. If, for instance, the user entered a keystroke that was not a number, you could either not accept the input or provide some sort of feedback mechanism to let the user know that they had entered a character that is invalid for a U.S. ZIP code. With a Web application, however, such functionality is not possible from the ASP.NET Web page's source code portion. This is because the ASP.NET Web page's source code portion only executes when the page is requested by the user's browser. This only happens when the page is first loaded, or when the page is submitted back via a button click or some other mechanism.

Sending a Value From One Web Form to Another

A common task in Visual Basic applications involves sending a value from one Form to another. For example, an employee database application might have one Form that lists the company's employees in a drop-down list, with information common to all of the employees. From that first Form, the user can select a particular employee and click a "Details" button, which will display a second Form with the selected employee's name, address, and salary information. Since Visual Basic desktop applications are connected and stateful, a common Module can be used to hold values common to all Forms, or the master Form could expose the selected value of its drop-down list to the detail Form.

Due to the disconnected and stateless nature of the Internet, the only time a Web Form is executed is when it is requested from a Web browser. Therefore, for one Web Form to load another Web Form, the user's browser must somehow be instructed to load the URL of the second Web Form. Values can be passed from one Web Form to another through the URL's QueryString. Before we discuss how to pass values between Web Forms via the QueryString, let's first examine theResponse.Redirect()method, which instructs a Web browser to request a specified URL. It is through this method that one Web Form can load another Web Form.

To show theResponse.Redirect()method in action, let's create an ASP.NET Web page that has a single Button Web control. When this Button is clicked, the user will be sent to a different Web Form. Start by creating the first Web Form, the one with the Button, and name it First.aspx. To create a new Web Form, right click on the project name, ASPNETCrashCourse, and select Add / Add New Web Form. To this Web Form, simply add a Button Web control, setting its Text property to the value, Click Me. Figure 9 shows a screenshot of Visual Studio .NET after creating this ASP.NET Web page and adding the Button Web control.

Figure 9. A Button Web control has been added to the First.aspx Web Form.

Next, double-click the Button Web control in the Designer in order to add an event handler for the Button's Click event. In this event handler, add the following line of code:

Response.Redirect("Second.aspx")

As you can see, theResponse.Redirect()method takes in a single string parameter, the URL to redirect the user's browser to. Now, create a Web Form called Second.aspx that simply has a Label Web control with a Text property value of, "Welcome to the Second Web Form."

Now, to start testing the First.aspx Web page you'll need to set First.aspx as the Start Page. Do so by right clicking on First.aspx in the Solution Explorer and choosing the Set as Start Page option. Then go to Debug and select the Start option, which will compile the ASP.NET Web pages' source code portions and launch a Web browser visiting First.aspx. This will display a button in the browser. This button, when clicked, will cause the browser to re-request First.aspx. Upon being requested, the source code portion of First.aspx will execute and the Button's Click event will fire, causing the event handler to execute. This will cause theResponse.Redirect()method to fire, which sends a message back to the user's Web browser instructing it to request Second.aspx. Second.aspx is then requested and the resulting output—Welcome to the Second Web Form—is displayed in the user's browser.

At this point we've seen how to useResponse.Redirect()to load a different Web Form in a user's browser. A set of simple scalar values—like strings, numbers, and dates—can be passed from one Web Form to another via the QueryString. The QueryString is additional text that is appended to a Web Form's URL, and contains a list of variable names and their values in the following format:

VariableName1=Value1&VariableName2=Value2&...&VariableNameN=ValueN

Note that each variable name and value pair is delimited by an ampersand, while each variable name is separated from its value by an equals sign. A URL, with an appended QueryString, looks like:

http://www.SomeSite.com/SomePage.aspx?SomeName=SomeValue&SomeOtherName=
  SomeOtherValue

Let's modify First.aspx so that in addition to its Button Web control it includes a TextBox Web control into which a user can enter some string. Then, in the Button Web control event handler, we'll modify theResponse.Redirect()method call so that the value of the string is passed along to the Second.aspx Web Form. Finally, in the Second.aspx Web Form we'll display the value of the string from the first Web Form in a Label Web control.

To start, add a TextBox Web control to First.aspx with an ID property of ValueToPass. In the Click event handler we need to pass along the value of the ValueToPass TextBox's Text property. This can be accomplished by changing the code in the event handler from:

Response.Redirect("Second.aspx")

To:

Response.Redirect("Second.aspx?TextBoxValue=" & 
  Server.UrlEncode(ValueToPass.Text))

TheServer.UrlEncode()method encodes the passed-in string parameter so that it is QueryString-safe. Older browsers do not allow certain characters in the QueryString, such as a space, and instead insist that these characters be escaped to safe equivalents (for example, space is escaped to +).Server.UrlEncode()kindly performs all of these escapes. Realize that with this change, when the button in First.aspx is clicked, the user's Web browser will end up requesting the URL: Second.aspx?TextBoxValue=ValueEnteredIntoTextBox. This will, in essence, pass in a QueryString variable named TextBoxValue into Second.aspx.

Now, in Second.aspx, we need to add a Label Web control with an ID property of Results. It is in this Label Web control that we'll display the value of the TextBoxValue QueryString value passed in. To accomplish this, view the source code portion of Second.aspx (this can be done by right-clicking on Second.aspx in the Solution Explorer and choosing View Code). Notice that in the source code portion there is a subroutine named Page_Load. This subroutine executes precisely once every time the ASP.NET Web page is loaded, and is the place to put code that you need to execute upon the page loading. So, in the Page_Load event handler, add the following line of code:

Results.Text = Request.QueryString("TextBoxValue")

Request.QueryString() is a NameValueCollection of the QueryString variables passed into the page. To access the value for a particular QueryString variable with name, name, use the syntax: Request.QueryString("name").

To demonstrate passing a value from one Web Form to another, go to Debug and choose the Start option. This should compile the source code and display First.aspx in your Web browser. Type into the TextBox, "Hello, World!" and then click the button. This will send you to Second.aspx, passing along in the QueryString the escaped version of "Hello, World!"—Hello%2c+World!. In Second.aspx, the unescaped value of the QueryString variable is displayed in the Label Web control, producing the output shown in Figure 10.

Figure 10. The TextBoxValue QueryString variable is displayed.

Realize that there are other ways to pass information from one Web Form to another, but a lengthy discussion on these other topics is beyond the scope of this article.

Conclusion

This article examined the increasing similarities between Web application development with ASP.NET and traditional Windows desktop application development. Like designing desktop applications, designing ASP.NET application with Visual Studio .NET involves creating a graphical user interface in a WYSIWYG Designer through the use of Web controls. Disjoint from this user interface is the ASP.NET Web page's source code portion, which is comprised of a class.

Despite the many similarities between desktop and Web applications, there are some important differences that provide limitations to the end-user's overall experience. The most profound difference is due to the different mediums over which desktop and Web applications are deployed on. Specifically, the various components of a desktop application enjoy a connected, stateful coexistence, whereas there is a physical divide between a Web application's front-end and back-end. This divide limits what the responsiveness of a Web site user interface, and makes certain tasks that are easy in Visual Basic desktop application development, exceedingly difficult in a Web environment.

If you're as excited about ASP.NET at this point as I hope you are, let me suggest the following resources for continuing your ASP.NET education.

• ASP.NET Kick Start, by Stephen Walther. (ISBN: 0672324768)
• 4GuysFromRolla.com
• ASPAlliance.com

These print and Web resources should help you get started with ASP.NET. In addition to the above resources, there are a number of excellent places to ask your ASP.NET questions and get quick, concise answers. If you enjoy online forums, be sure to utilize the ASP.NET Forums, which is a very active forum for ASP.NET developers of all skill levels. If you prefer email listservs, be sure to sign up for the many targeted listservs at ASPAdvice.com.

Happy Programming!

About the Author

Scott Mitchell, author of five ASP/ASP.NET books and founder of 4GuysFromRolla.com, has been working with Microsoft Web technologies for the past five years. An active member in the ASP and ASP.NET community, Scott is passionate about ASP and ASP.NET and enjoys helping others learn more about these exciting technologies. For more on the DataGrid, DataList, and Repeater controls check out Scott's book ASP.NET Data Web Controls Kick Start (ISBN: 0672325012).

© Microsoft Corporation. All rights reserved.