Using ASP.NET with FrontPage 2003
Microsoft® Office FrontPage®
Summary: Discover how to create and edit ASP.NET pages with Microsoft Office FrontPage 2003, which adds significant new functionality for working with ASP.NET pages. (8 printed pages)
Setting Up ASP.NET Options
Working with ASP.NET Pages
One of the exciting new features in Microsoft® Office FrontPage® 2003 is the ability to create and edit ASP.NET pages. Although Microsoft Visual Studio® .NET has more features for advanced ASP.NET programming, FrontPage 2003 adds significant new functionality for working with ASP.NET pages.
ASP.NET is Microsoft's newest technology for creating Web applications and Web services with Internet Information Server (IIS). It is important to know, however, that ASP.NET is not platform-independent. Because it is hosted by IIS, ASP.NET must run on Windows-based servers that have the Microsoft .NET Framework installed. Therefore, you cannot use FrontPage 2003 to create ASP.NET pages that are hosted on non-Windows-based servers, such as those running Linux or Apache.
ASP.NET is part of the .NET Framework, built on top of the common language runtime (CLR)—a rich, flexible architecture designed to not only cater to the needs of developers today but to allow for future development. ASP.NET isn't just a new kind of ASP—ASP.NET has been rewritten from the ground up. For more information about ASP.NET, see ASP.NET or the ASP.NET QuickStart Tutorial.
Microsoft's main development platform for creating ASP.NET Web applications has been Microsoft Visual Studio .NET. Now, with the release of FrontPage 2003, users can take advantage of the powerful professional design, authoring, data, and publishing tools in FrontPage to create high-end dynamic Web sites with ASP.NET. FrontPage incorporates many new tools and features that make it a more robust development environment than ever before.
Setting Up ASP.NET Options
FrontPage requires no special settings or configurations to get started working with ASP.NET. However, you can specify some of the environment and interface defaults when developing ASP.NET pages.
Location for ASP.NET Control Assemblies
When working with ASP.NET, you might need to create or manage ASP.NET control assemblies. Assemblies are the executable components of an application created using the .NET Framework. Web applications compile their executable code into an assembly file that has a .dll file extension. The compiled code is in Microsoft Intermediate Language (MSIL), which is compiled at run time by the just-in-time (JIT) compiler.
Unless you are creating your own assemblies, FrontPage users do not need to create the control assemblies, because that task is handled by ASP.NET. You can use Visual Studio .NET to create custom control assemblies, and FrontPage to create the ASPX pages that use them. However, you might want to specify the default location for ASP.NET control assemblies on the server or in the current Web site. Typically all .NET assemblies are located in either the global assembly cache (GAC) or the /bin folder within your Web site. In order for FrontPage to instantiate a control assembly and have it available during design time, the control must be installed into the GAC on the machine running FrontPage.
The GAC is a special subfolder in a Windows-based server that stores shared .NET assemblies. If you want to share your assembly with all other applications or Web sites on a server, you can store them in the GAC. Installing .NET assemblies into the GAC isn't as simple as copying the files to a folder. The process requires special tools and is beyond the scope of this article. The /Bin folder, which is located in the root folder for a Web application, is a special folder that contains application assemblies or custom controls and components. If this folder does not already exist, you can create it. Placing control assemblies into this folder makes them automatically visible to all pages within your Web site if the control assembly is located on the local file system or a UNC share.
To specify the default location for control assemblies in FrontPage
- From the Tools menu, choose Options.
- In the Options dialog box, click on the ASP.NET tab.
From this tab, you can browse to the location on your Web server, or in your Website, where you want to store your assemblies. For more information about the global assembly cache, see the .NET Framework Developer's Guide.
Another new feature in FrontPage is the incorporation of IntelliSense technology, which provides auto-completion of commands and context-sensitive lists that contain code and scripting elements. IntelliSense is available when you are working in Code view. For example, if you are working on an ASP.NET page in Code view and you type a less-than symbol (<), you see a drop-down list with all of the various commands and tags available to you.
To customize the use of IntelliSense in FrontPage
- From the Tools menu, chose Page Options.
- In the Page Options dialog box,****click the IntelliSense tab.
From this tab, you can turn IntelliSense on or off or change some of the auto-insert features, such as automatically inserting closing tags once you finish typing.
Working with ASP.NET Pages
You can open and work with several ASP.NET file types in FrontPage. If you choose Tools and then Options from the menu bar, and click the Configure Editors tab, you can see which file extensions you can open with FrontPage. ASP.NET files typically have an .aspx file extension. However, you might encounter other types of files. For example, when you create a database connection, FrontPage also creates an /_Fpclass folder, as it does with ASP pages. The difference is that when you are using ASP.NET, FrontPage includes a number of configuration files and utilities for working with ASP.NET pages and database connections. These files are called "user controls" and have an .ascx file extension.
In addition to .aspx and .ascx files, you might also see files that end in .cs or .vb in your Web site. These types of files are called class files and generally have the same file name as the page with which they are associated. You can also use class files in code-behind pages, which is discussed later in this article. For example, if you had a Default.aspx page, you might also see a Default.cs or Default.vb page as well. The .cs extension indicates that the code was written in C# (pronounced "see sharp"), and the .vb extension indicates files written in Microsoft Visual Basic® .NET.
If you are looking at a file created in Visual Studio .NET, you might see the naming convention Default.aspx.vb or Default.aspx.cs. Visual Studio .NET uses this naming convention to track the class file that is related to the Web Form. This enables Visual Studio .NET to automatically embed code in the class file when the design environment changes, such as when a new server control is placed on the Web Form. This is a Visual Studio .NET convention and is not required for ASP.NET class files or code-behind pages.
Choosing a Language
Although there are many .NET-based programming languages, FrontPage uses C# as the default language whenever you use one of the FrontPage wizards to create ASP.NET pages. When developing your own pages in FrontPage you can use any .NET-compatible language.
So which language should you choose? Since Microsoft introduced the .NET Framework, there have been many articles and discussions about which of the .NET languages is the best. The two predominant languages are Microsoft Visual C#® and Visual Basic .NET. Because all .NET-compatible languages use the CLR, Visual Basic and C# are equally powerful. The choice really depends on your background and prior programming experience. If you come from an ASP, Visual Basic, or VBScript background, you find Visual Basic .NET to be the best choice for you. If you come from a Java, C, or C++ background, the syntax in C# is more familiar to you. Regardless of the language you choose, FrontPage allows you to create, open, and edit any ASP.NET page.
Working with Web Forms and User Controls
Unlike classic ASP, ASP.NET pages are known as Web Forms. Web Forms are the central user interface component within an ASP.NET Web application. Web Forms have an .aspx file extension. In FrontPage, you can create your own Web Forms or work with a Web Form created in Visual Studio .NET. Web Forms contain HTML code as well as new ASP.NET server controls. ASP.NET server controls are the visual components used on a Web Form to create the user interface or layout for your Web application.
Because these controls run on the server, they contain a
statement. By adding the
attribute to your form elements, your server tags become ASP.NET server controls. Because they become server controls, you have programmatic access to them by using their ID property. For example, an ASP.NET button control looks like this:
<asp:Button id="myButton" />
Note that some server controls end in a trailing slash to indicate the end of the tag. This is called an immediate close and is part of the W3C XML Standard. Some require embedded content and therefore cannot be closed immediately. Alternatively, you can also end the element with a closing tag such as the following:
<asp:Button id="myButton" ></asp:Button>
This is a sample ASP.NET page created in FrontPage:
<%@ Page Language="VB"%> <script > Sub Button_Click( s As Object, e As EventArgs ) lblMessage.Text = "Hello!" End Sub </script> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <html> <head> <title>Sample ASP.NET Page</title> </head> <body> <form Runat="Server"> <asp:Button Text="Click Here!" OnClick="Button_Click" Runat="Server" /> <p> <asp:Label ID="lblMessage" Runat="Server" /> </form> </body> </html>
In the preceding sample, when the button is clicked the value of "Hello!" is assigned to the Label control named "lblMessage" and is displayed on the screen. As you can see, although C# is the default language used when running the Database Region Wizards, you can use your choice of languages when creating ASP.NET pages in FrontPage.
In addition to server controls, you can also use and create user controls. FrontPage creates some user controls for you in the /_Fpclass folder, but you can also create your own user controls to use in your Web pages. Some typical uses for user controls include a common header, footer, or navigation menu system on all of your pages. If you want a common header on all of your pages, create the page in Design view and then save the file with an .ascx file extension. You can then save the file in any folder in your Web site. Because user controls do not have to be compiled, you can create and use them immediately in your pages. The following example shows a user control that creates a header for each Web page:
<%@ Control %> <table width="100%" border="0"> <tr> <td valign="top">This is my Header</td> </tr> </table>
Note that the very first line of the page contains the
@Control directive. This indicates that you are creating a user control. Now you can reference the control in all of your pages as follows:
<%@ Page Language="VB"%> <%@ Register TagPrefix="UC" TagName="header" Src="/global/header.ascx" %> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML> <HEAD> <title>My ASP.NET Page</title> </HEAD> <BODY bgcolor="#ffffff"> <UC:header id="header" /> <FONT SIZE="3">This is the Main Page</FONT> </BODY> </HTML>
In this example, you add a reference to the user control that you created by adding the
@Register directive to the top of the page. Inside the directive, give your user control a TagPrefix attribute and a TagName attribute (so you can refer to it later) and the location where the control resides in your Website; in this case, the /Global folder.
When you want to use the control in your page, reference the TagPrefix attribute followed by a semicolon and the TagName value, such as UC:header. This line tells ASP.NET that this is where you want your control to appear. The preceding sample is the same as using a FrontPage include page or an ASP include file, although you can create many types of user controls that can display information or respond to events on a page.
Separating Code from Content
Another powerful feature of ASP.NET is the ability to separate code from content using code-behind pages. As I discussed previously, Web Forms can have class files associated with them and can have a .cs or .vb file extension, depending on the .NET language that you are using. You can use the class files as code-behind pages. By using code-behind pages, you can design your Web pages and keep all of your code in separate files, making it easier to work with your pages without worrying about deleting critical areas that contain code. ASP.NET pages associate their code-behind pages in the **@Page** directive.
<%@ Page Inherits="myCodeBehind" src="myCodeBehind.vb" %>
The preceding code example indicates that the ASP.NET page you created has a code-behind page named myCodeBehind.vb, which contains commands and events that execute at run time. If you copied the previous sample page and put the code into a code-behind page, it looks like the following:
<%@ Page Inherits="myCodeBehind" src="myCodeBehind.vb" %> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <html> <head> <title>Sample ASP.NET Page</title> </head> <body> <form Runat="Server"> <asp:Button Text="Click Here!" OnClick="Button_Click" Runat="Server" /> <p> <asp:Label ID="lblMessage" Runat="Server" /> </form> </body> </html>
Imports System Imports System.Web.UI Imports System.Web.UI.WebControls Imports System.Web.UI.HtmlControls Public Class myCodeBehind Inherits Page Protected WithEvents lblMessage As Label Sub Button_Click( s As Object, e As EventArgs ) lblMessage.Text = "Hello!" End Sub End Class
Note that the code-behind page contains other statements that import various namespaces from the .NET Framework to use in the page. This is because .aspx pages import these namespaces by default, but in a code-behind page, you must explicitly import them. It is also important to note that you cannot preview code-behind user controls at design time in FrontPage. This topic is beyond the scope of this article, but you can see the ASP.NET QuickStart Tutorial for more information.
Connecting to a Database
When you are working with ASP.NET pages, the way that you connect to a database in FrontPage is the same as in previous versions of FrontPage—with three notable exceptions. In previous versions of FrontPage, when you connected to a database, FrontPage created a global.asa file, a /Fpdb folder and a /_Fpclass folder in your Web site. FrontPage also creates these same elements along with other files specific to ASP.NET Web applications.
One of these files, the web.config file, is created at the root folder of your Web site. A web.config file is a special XML file that facilitates configuration of your ASP.NET application. Everything in a web.config file is surrounded by the <configuration>. . .</configuration> opening and closing tags. Between those tags, FrontPage specifies application settings for your Web site, and you can add your own settings to this file. The following is an example of the web.config file generated by FrontPage:
<configuration> <appSettings> <add key="Sample_Provider" value="Microsoft.Jet.OLEDB.4.0"/> <add key="Sample_DataSource" value="fpdb/fpnwind.mdb"/> <add key="Sample_ConnectionTimeout" value="15"/> <add key="Sample_CommandTimeout" value="30"/> <add key="Sample_CursorLocation" value="3"/> <add key="Sample_RuntimeUserName" value=""/> <add key="Sample_RuntimePassword" value=""/> </appSettings> </configuration>
By adding keys that define global settings that can be used within your ASP.NET pages, you can include the database connection information in the appSettings element of the XML file. Because the database connection information is stored in a web.config file, you can reference it in your ASP.NET pages by specifying the location as such:
Dim dbName as string = ConfigurationSettings.AppSettings("Sample")
The value, specified as "Sample," indicates the name of the key added to the appSettings section of the web.config file for the data source that you use.
When developing classic ASP pages, you might use a file named global.asa to define database connection strings, among other things. ASP.NET pages do not use the global.asa file, even though FrontPage creates one for you. If you need to use Application or Session events for your ASP.NET pages, you need to create a global.asax file. The global.asax file is similar to the global.asa file, although it has more events you can use. The important things to note are that you can have both a global.asa and a global.asax file in the root of your Web site. ASP and ASP.NET pages can run side by side and use different worker processes on the server. The difference is that ASP.NET pages cannot use the global.asa file and ASP pages cannot use the global.asax file. If you use both types of pages in your Web site, you need both files.
By adding the ability to create and work with the various types of ASP.NET pages and files, Microsoft Office FrontPage 2003 is a powerful tool for developing Web applications. This functionality allows FrontPage users to use the advanced design and content management features of FrontPage while creating rich and dynamic Web applications built on the Microsoft .NET Framework. This is an important advancement for FrontPage.
About the Author
David Berry has an extensive background in technical and IT skills, Web site design work, application development, and technical support with more than 17 years of diverse experience with government and federal agencies as well as competitive business markets. He is also a Microsoft Certified Professional and has been a Microsoft FrontPage Most Valuable Professional (MVP) since 1999. David co-authored Microsoft FrontPage 2002 Unleashed, Microsoft FrontPage 2000 Unleashed, and Microsoft Windows 2000 Professional Unleashed.