Microsoft Office FrontPage 2003 Inside Out

 

This article is an excerpt from Microsoft Office FrontPage 2003 Inside Out from Microsoft Press (ISBN 0-7356-1510-1, copyright Microsoft Press 2003; all rights reserved). The author, Jim Buyens, is a FrontPage MVP and a noted expert on Web programming and networking. He develops Web-based business systems for the telecommunications industry and has written several books, including Microsoft FrontPage 2002 Inside Out*,* Faster Smarter Beginning Programming*, and* Web Database Development Step by Step .NET Edition*, all from Microsoft Press.*

No part of these chapters may be reproduced, stored in a retrieval system or transmitted in any form or by any means—electronic, electrostatic, mechanical, photocopying, recording or otherwise—without the prior written permission of the publisher, except in the case of brief quotations embodied in critical articles or reviews.

Chapter 43: Using FrontPage 2003 and Visual Studio .NET Together

Contents

Choosing the Correct Version of Visual Studio .NET
Collocating ASP.NET Projects and FrontPage-Based Web Sites
Reconciling the FrontPage Folder List and the Visual Studio Solution Explorer
Comparing the Inline and Code-Behind Models for Code
Choosing Compatible Page Design Features
Selecting the FrontPage or Visual Studio .NET Publishing Model

Compared to earlier versions, Microsoft Office FrontPage 2003 provides more and better features than ever for working with code. Even so, FrontPage makes no claims of being a complete and integrated software development environment. That distinction goes to Microsoft Visual Studio .NET 2003.

Visual Studio is Microsoft's top-tier platform for developing software of all kinds, and that includes software that runs on Web servers. Specifically, Visual Studio .NET is the preferred development environment for Microsoft ASP.NET Web pages. Visual Studio includes not only a full-bore programmer's code editor, but a graphical HTML editor as well. Unfortunately, this HTML editor lacks many of the tools and conveniences that FrontPage provides.

Because each product has different strengths, Web designers typically prefer FrontPage, and Web programmers usually prefer Visual Studio, even if people with both specialties are working on the same project. Individuals who perform both roles might prefer to switch between products, depending on the task at hand. This chapter explains how these two pieces of software (and their corresponding approaches to creating Web pages) can coexist peacefully.

This chapter isn't an introduction to Visual Studio, or to programming in general. It presumes that you already know how to use both Visual Studio and FrontPage, and that you now want the freedom to choose between them for a particular task.

Choosing the Correct Version of Visual Studio .NET

Product packaging is subject to frequent change, but the initial release of Visual Studio .NET 2003 included four editions designated as Standard. These standard editions include most of the Visual Studio development environment, but only one programming language. In addition, the graphical database tools that Visual Studio provides will work only with Microsoft Access databases and with local MSDE databases.

Note   The Microsoft Data Engine (MSDE) is a run-time version of SQL Server that includes only rudimentary administration tools.

The four packages are:

• Microsoft Visual Basic .NET Standard   BASIC is one of the most widely known programming languages in the world. In addition, most developers who wrote classic ASP applications did so in VBScript. Visual Basic .NET is the most powerful and sophisticated version of BASIC ever released.

• Microsoft Visual C# .NET Standard   Visual C# is a professional programming language similar in syntax to JavaScript, Java, and C++, but tailored specifically for .NET programming.

  Visual Basic .NET and Visual C# .NET are by far the most popular languages for developing ASP.NET pages.

• Microsoft Visual J# .NET Standard   Visual J# .NET provides an implementation of the Java programming language, but frankly, most programmers who want to work in Java do so on a non-Windows platform.

• Microsoft Visual C++ .NET Standard   Visual C++ is by far the most difficult of these four languages to use for ASP.NET programming. As a result, and despite a bit of a learning curve, most C++ programmers switch to Visual C# for ASP.NET development.

The greatest attraction of these single-language editions is their low price. Typically, you can purchase them for about the same price as a copy of FrontPage. If you need only one programming language and you require only simple database features, purchasing one of these editions is an excellent way to get started.

If you need multiple programming languages or full graphical database features, the following editions of Microsoft Visual Studio .NET will provide a better match. Each includes all four of the languages mentioned earlier, plus an increasing number of design, database, and testing tools.

• Microsoft Visual Studio .NET Professional
• Microsoft Visual Studio .NET Enterprise Developer
• Microsoft Visual Studio .NET Enterprise Architect

Many companies and consultants purchase Video Studio as part of a Microsoft Developer Network (MSDN) subscription. For an annual fee, an MSDN subscription provides licensing for a designated bundle of Microsoft applications, operating systems, and development tools, including Visual Studio.

Of the many editions of Visual Studio .NET, at least one will almost certainly be cheap enough or full-featured enough to meet your needs. The information in the rest of this chapter applies to all editions of Visual Studio .NET, including the single-language Standard editions.

Collocating ASP.NET Projects and FrontPage-Based Web Sites

To create ASP.NET Web pages in Visual Studio, you must first create an ASP.NET project. This is a group of ASP.NET pages and related files that Visual Studio manages as a unit. ASP.NET projects and FrontPage-based Web sites are quite analogous, and both can exist in the same physical folder tree.

Here's the procedure for creating a new ASP.NET project:

1. Choose New from the Visual Studio .NET File menu, and then choose Project from the submenu. (Alternatively, click New Project on the Visual Studio .NET Start Page.) This will display the New Project dialog box, shown in Figure 43-1.

   

   Figure 43-1. This dialog box creates a new Visual Studio project. An ASP.NET Web application can also be a FrontPage-based Web site.

2. Configure the New Project dialog box as follows:

   • Project Types Select the entry that corresponds to the programming language you want to use for your project. In most cases, this will be Visual Basic Projects or Visual C# Projects.
   • Templates Select ASP.NET Web Application.
   • Location Specify the *http://*URL, file sharing location, or local drive and path where you want the project to reside.

3. Click OK.

   Note   When you create a Visual Studio project, Visual Studio also creates a solution. This is simply a file (with a .sln file extension) that contains the location and overall settings for one or more projects. Opening a solution opens each project it names. If you directly open a project file (which has a file extension such as .vbproj), Visual Studio will create a solution that refers to that project.

Even if you specify a file sharing location or local drive and path in step 3, the location you specify must reside within the content tree of an IIS Web server and the server must have the Microsoft .NET Framework installed. If Visual Studio can't verify both of these conditions, it won't accept the address. If it can verify both conditions, Visual Studio will save both the physical path and the *http://*URL path as project properties.

Regardless of the type of location you specify, Visual Studio will use the physical path if possible. In Figure 43-2, for example, the full path to the styles.css file shows up as c:\inetpub\wwwroot\myproj\styles.css, even though in Figure 43-1 the designer specified an *http://*location for the entire project.

Figure 43-2. Solution Explorer shows the files in a Visual Studio project. The Properties window shows the attributes of the current file or element.

If you want, you can create a disk-based, FrontPage-based Web site at the same physical location as an ASP.NET project (or vice versa). In this configuration, however, the disk-based, FrontPage-based Web site has no way of knowing what changes you make in Visual Studio. If you add, change, or delete any files in Visual Studio, FrontPage won't correct any hyperlinks or FrontPage components in the site. You can avoid this situation by telling Visual Studio to access the project via the FrontPage Server Extensions. Here's the procedure:

1. Verify that the FrontPage Server Extensions are installed on the Web server where the ASP.NET project resides. If not, install them.

2. Open your ASP.NET project in Visual Studio, using an http://URL.

3. Choose <project-name> Properties from the Project menu, or right-click the project in Solution Explorer, and then choose Properties from the shortcut menu. This displays the <project-name> Property Pages dialog box, as shown in Figure 43-3.

4. Under Common Properties, select Web Settings.

5. Under Web Access Method, select FrontPage.

6. Click OK to close the dialog box, and then close and reopen the entire project.

7. Repeat steps 3 and 4, and then, under Web Access Method, make sure that the FrontPage Link Repair check box is selected.

8. Click OK to close the dialog box.

   

   Figure 43-3. Use this panel of the project Property Pages dialog box to specify that Visual Studio should use the FrontPage method for accessing files in a project.

If you specify an *http://*location for a new ASP.NET project and Visual Studio can't determine the project's physical file location, the Web Access Failed dialog box shown in Figure 43-4 will appear. If the Web server is running the FrontPage Server Extensions, you can proceed by selecting Try To Open The Project With FrontPage Server Extensions and then clicking OK. If this succeeds, Visual Studio will thereafter access the project via FrontPage, and you won't have to worry about FrontPage indexes, cross-references, hyperlinks, and components getting out of date.

Figure 43-4. If Visual Studio can't use a file share to access a project, it displays this dialog box offering FrontPage as a second option.

Once both FrontPage and Visual Studio can open the same site, you should take care not to open the same file in both programs at the same time. If you do, and make changes and then save the file in both programs, you'll lose the set of changes you saved first.

You should also take special care when organizing files or folders in a FrontPage/Visual Studio site:

• Never use FrontPage to move, rename, or delete files that are part of a Visual Studio project. The relationships among files in a Visual Studio project are complex, and FrontPage lacks the capability to keep these relationships up-to-date. If you must perform file maintenance to Visual Studio files, do so in Visual Studio.

• Before using either program to move, rename, or delete files, close all files in the other program.

  Suppose, for example, that you rename a file in FrontPage. This starts a ripple effect that can modify hyperlinks or other content in dozens of other files. If, when this occurs, one of the affected files is open in Visual Studio, saving the Visual Studio file at a later time will overwrite the change that FrontPage made.

  Similar problems can occur if you move, rename, or delete files in Visual Studio when the same (or related) files are open in FrontPage.

Reconciling the FrontPage Folder List and the Visual Studio Solution Explorer

Visual Studio has a Solution Explorer window that displays the projects within a solution, and all the files within each of those projects. A Solution Explorer window appears in the upper right corner in Figure 43-2.

At first glance, you might think that the list of files in Solution Explorer and the list of files in the FrontPage Folder List ought to be the same. In fact, these lists are generally quite different. For proof, compare the Folder List in Figure 43-5 to Solution Explorer in Figure 43-2.

Figure 43-5. The Visual Studio Solution Explorer doesn't display all the files in a project folder. FrontPage displays many files that Visual Studio doesn't.

According to FrontPage, this site contains two subfolders and eleven files. According to Visual Studio, it contains a References node, no folders, and five files!

In fact, the information that Solution Explorer displays is distinctly not a folder listing. Instead, it's a list of files that Visual Studio will need when it compiles the project. Visual Studio keeps this list in the project file (in this case, myproj.vbproj).

Tip   If you're a longtime programmer, it might help to think of a Visual Studio project file as a make file and Solution Explorer as a make list.

Notice that Visual Studio shows one file named WebForm1.aspx, but FrontPage shows three files named WebForm1.aspx, WebForm1.aspx.resx, and WebForm1.aspx.vb:

• The .aspx file contains the HTML.
• The .aspx.resx file contains any messages or other text strings that the programmer cares to define.
• The aspx.vb file contains the program code for the page.

Visual Studio treats these three files as one ASP.NET Web form, and therefore displays only one icon. FrontPage sees them as three files, and therefore displays three icons. Similar thinking applies to the global.asax file and the myproj.vbproj file.

The images folder that FrontPage displays requires no compilation, and therefore doesn't appear as part of the Visual Studio project. When Visual Studio compiles the project, it places the resulting DLL (and possibly a debugging file) in the bin folder. Solution Explorer doesn't display this folder because the programmer doesn't (and shouldn't) manipulate these files directly in Visual Studio.

The References node contains a list of programming components set up for ready access throughout the project. These can be .NET class libraries, COM components, or Web services, but they aren't files in the ordinary sense and won't appear in FrontPage.

In most cases, the fact that Solution Explorer displays only files having programming relevance decreases clutter and makes Visual Studio easier to use. If, however, you really need to see a complete file and folder listing, try this procedure:

1. In Solution Explorer, select the node for your project.
2. Choose Show All Files from the Project menu.

This will display all the files and subfolders in the folder where the project begins. Files that are part of the project will appear normal, and others will be dimmed. If the display seems out-of-date, select the project node, and then choose Refresh from the Project menu.

Tip   In Visual Studio, the F5 key doesn't mean Refresh. Instead, it means Start Debugging. To perform a refresh operation, choose Refresh from the Project menu.

If you add a file in Visual Studio and then display the file area in FrontPage, the new file might not appear. If this happens, click anywhere in the FrontPage Folder List or Folders view, and then press F5 (Refresh).

If you add a file in FrontPage and want to make it part of a Visual Project, use either of these procedures:

• If Show All Files is in effect, right-click the dimmed file in Solution Explorer, and choose Include In Project from the shortcut menu.

• If Show All Files is off, right-click the project node in Solution Explorer, choose Add from the resulting shortcut menu, and then choose Add Existing Item.

  This displays a standard Open File dialog box titled Add Existing Item. Select the file you want to add, and then click Open.

To remove a file from a project, right-click its name in Solution Explorer, and choose Exclude From Project from the shortcut menu.

Comparing the Inline and Code-Behind Models for Code

If you ever used FrontPage to work with ASP pages, you probably put your ASP code inside <% and %> tags. These tags define a code render block, meaning a block of code that executes when the Web server creates the HTML code for the page (that is, when the Web server renders it). The Web server scans the page as it leaves the server and executes code render blocks at the time it encounters them.

Code declaration blocks provide a second way of adding program code to a Web page. A code declaration block begins with a <script > tag and ends with a <script> tag. The Web server doesn't execute code declaration blocks immediately; instead, the Web server saves the code until another piece of code calls it.

Note   ASP.NET pages generally use code declaration blocks (<script > and </script> tags) rather than code render blocks (<% and %> tags). Standardized events cause specially named subroutines inside the code declaration blocks to run.

Code render blocks and code declaration blocks both reside in the same file as the HTML. This is convenient when the same person develops both the visual design and the program code for a page, and it's the only model FrontPage supports for working with ASP and ASP.NET code. However, this inline code model has drawbacks as well:

• It leads to confusion when different people perform design and programming tasks.
• It requires that your program code be present in the Web site that your visitors access. This makes your source code vulnerable to theft by intruders.
• Neither FrontPage nor Visual Studio provides Microsoft IntelliSense support for inline ASP.NET code.

To avoid these drawbacks, Visual Studio manages source code using a code-behind model. In this model, the HTML and the program code reside in separate files. Before you test your site or cut it to production, you compile all the program code for all the pages and other modules in a project and link the results into one executable file (a .dll file in the bin folder, to be exact). This DLL contains, among other things, a class for each Web page in the project. When a Web page runs, it inherits its corresponding class and thereby gains access to its program code.

If it seems like quite a chore to manage all these separate files (and the relationships among them), you're right. Fortunately, it's a chore that Visual Studio does very well and with very little intervention from you. Just take heed of this advice:

• Visual Studio provides two views of any Web page you open: Design view and HTML view. These are generally analogous to Design view and Code view in FrontPage, and you switch between them in much the same way. Just click the Design or HTML tab that appears at the bottom of the Web Forms Designer window (and in Figure 43-2).

  If you're accustomed to working with ASP pages, it might surprise you that your source code doesn't appear in HTML view. To enter, view, or correct source code, right-click the Web Forms Designer window (either Design view or HTML view will do), and then choose View Code. This displays your source code in a new window that has its own tab at the top of the Visual Studio editing window.

Note   In Figure 43-2, the WebForm1.aspx.vb tab identifies the source code for the WebForm1.aspx page.

• You can edit source code files in FrontPage, but neither IntelliSense nor compilation features will be available. As a result, most developers prefer Visual Studio for working with source code.

Tip    To open source code files in FrontPage, open the .vb or .cs file you want as text.

• When publishing your site, you must include the DLL that Visual Studio creates in your site's bin directory. There's generally no reason, however, to publish .vb, .cs, .resx, and other source code files.

Choosing Compatible Page Design Features

Visual Studio includes a graphical HTML editor called the Web Forms Designer that, at a high level, is generally analogous to FrontPage Design view. Nevertheless, at a detail level, these two editors are completely different. Most Web designers will probably prefer FrontPage Design view, whereas most programmers will likely opt for the integration and object support that the Visual Studio Web Forms Designer provides.

This section describes some of the most significant differences between these two programs and how to reconcile them.

Choosing a Compatible Browser Schema

Both FrontPage and Visual Studio mark each Web page with the browser you had in mind when you designed the page. If, for example, you target Microsoft Internet Explorer 5 when you design a page, both FrontPage and Visual Studio will add the following meta tag to that page:

<meta name=vs_targetSchema content="http://schemas.microsoft.com/intellisense/ie5">

The setting in this tag controls the options that IntelliSense displays and, to some extent, the kind of HTML that FrontPage and Visual Studio create. In addition, Visual Studio displays warning messages for any HTML that's not compatible with the schema you specify.

FrontPage assigns the same target schema to all pages that a given Web designer creates using a given computer. To review or modify the setting in effect for you:

1. Choose Page Options from the Tools menu, and then click the Authoring tab.
2. Use the Browsers drop-down list to specify the browser you want, and then click OK.

Visual Studio controls the target schema setting at either the page or the project level. To change the target schema for a specific page:

1. Open the page in the Visual Studio Web Forms Designer.

2. Right-click anywhere in the page background, and then choose Properties from the shortcut menu. This displays the Document Property Pages dialog box, shown in Figure 43-6.

   

   Figure 43-6. Use this dialog box to set the target schema and page layout mode for a Web page.

3. Select the browser you want from the Target Schema drop-down list, and then click OK.

Visual Studio's default target schema is Internet Explorer 3.02/Netscape Navigator 3.0. To choose a different default for any new pages you add to a project, proceed as follows:

1. Choose Properties from the Project menu. Or, if you prefer, right-click the project node in Solution Explorer, and then choose Properties from the shortcut menu.

2. When the <project-name> Property Pages dialog box shown in Figure 43-7 appears, open the Common Properties node, and then select Designer Defaults.

3. Select the browser you want in the Target Schema drop-down list, and then click OK.

   

   Figure 43-7. Use this panel of the <project-name> Property Pages dialog box to set the default target schema and page layout mode for a project.

Choosing a Compatible Page Layout Mode

The Visual Studio Web Forms Designer offers two distinct methods for placing content on a Web page:

• **Grid layout **  Uses CSS positioning to specify exact xy-coordinates for every element on the page. This makes the job of designing Web forms very much like that of designing Windows forms, but it places great demands on browser compatibility. This mode is the Visual Studio default.
• **Flow layout   **Arranges content from left to right and from top to bottom within the browser window. This is the longtime HTML and FrontPage default.

Most Web designers prefer flow layout, and this requires overriding the Visual Studio default. To do this for a single page:

1. Open the page in the Visual Studio Web Forms Designer.
2. Right-click anywhere in the page background, and then choose Properties from the shortcut menu.
3. When the Document Property Pages dialog box shown in Figure 43-6 appears, select FlowLayout in the Page Layout drop-down list, and then click OK.

To change the default page layout mode for all new pages you add to a project, use this procedure:

1. Right-click the project node in Solution Explorer, and then choose Properties from the shortcut menu. (Alternatively, choose Properties from the Project menu.)

   This displays the <project-name> Property Pages dialog box shown in Figure 43-7.

2. Under Common Properties, select Designer Defaults.

3. Select Flow from the Page Layout drop-down list, and then click OK.

Changing a project's default page layout mode to flow layout doesn't affect any pages that already use grid layout. It affects only pages that you add to the project.

If you use grid layout in Visual Studio and then open the same page in FrontPage, you should specify absolute positioning for any page elements you add. To do this:

1. Add the element you want to the page.
2. With the new item selected, take either of these actions:
   • Click the Position Absolutely button on the Positioning toolbar.
   • Choose Position from the Format menu. When the Position dialog box appears, under Positioning Style, select Absolute, and then click OK.

Once absolute positioning is in effect for an element, you can drag the element into any position you want.

Controlling HTML Format

FrontPage takes great care to preserve the formatting of existing HTML and provides detailed control over the format of any new HTML it creates. It never reformats an entire page of HTML unless you issue a specific, manual command.

Visual Studio takes a much more cavalier attitude toward HTML formatting. It reformats HTML at will, makes no effort to preserve existing HTML formatting, and provides little control over the results. To exercise what control Visual Studio does provide, take these steps:

1. Open Visual Studio, and then choose Options from the Tools menu.

2. When the Options dialog box shown in Figure 43-8 appears, open the Text Editor node, and then open the HTML/XML node.

3. Configure the resulting settings, and then click OK.

   

   Figure 43-8. This panel of the Options dialog box controls HTML formatting options. Other panels in the HTML/XML category control additional HTML view and formatting options.

Here are the available HTML/XML options:

• Apply Automatic Formatting   Specify when, if ever, you want Visual Studio to reformat your HTML code:
  • When Saving Document Select this check box if you want Visual Studio to reformat your HTML code whenever you save a Web page.
  • When Switching From Design To HTML/XML View Select this check box if you want Visual Studio to reformat your HTML code whenever you switch from Design view to HTML view.

Tip   To deliberately reformat HTML code, first switch to HTML view. Then choose Advanced from the Edit menu, and then choose Format Document.

• **Automatic Formatting Options   **Specify the following formatting options:

  • Apply Line Breaks Select this check box if you want Visual Studio to insert line breaks before and after certain HTML tags.
  • Insert Attribute Value Quotes Select this check box if you want Visual Studio to add or retain quotation marks around attribute values (for example, align="center").

• **Capitalization   **Specify how you want Visual Studio to capitalize tag and attribute names when it reformats HTML:

  • Tags Specify how you want Visual Studio to capitalize tag names when it automatically reformats HTML. Table 43-1 lists the available options.
  • Attributes Specify how you want Visual Studio to capitalize attribute names when it reformats HTML. Again, Table 43-1 lists the options.

  Table 43-1. HTML Capitalization Settings

  Option	Result
  As Entered	Retains element case exactly as you entered it
  Uppercase	Changes element names to uppercase
  Lowercase	Changes element names to lowercase

Avoiding FrontPage Component Problems

Many FrontPage components that operate at browse time don't work in ASP.NET pages. This particularly affects components that use the FrontPage SmartHTML Interpreter—components like Save Results.

The SmartHTML Interpreter is a program named shtml.dll that comes with the FrontPage Server Extensions. This program examines each normal Web page that a FrontPage-extended Web site delivers and customizes the content of certain components. Unfortunately, this process doesn't work on ASP or ASP.NET pages. Such pages follow a different path out of the server: a path that bypasses the shtml.dll program.

Generally, this lack of compatibility is a lesser problem than you might suspect. If the FrontPage Save Results component could meet your needs, you probably wouldn't have written an ASP.NET page in the first place. Nevertheless, if you have an ASP.NET page that needs to save form results in a file or send them as e-mail, you should plan on writing your own ASP.NET code to do the job.

Components that format and arrange page content are less troublesome, but you should still be cautious. Although FrontPage stops you from modifying certain kinds of content, such as the non-editable portion of Dynamic Web Templates and the individual appearance of elements controlled by themes, Visual Studio enforces no such restrictions. At first, this might seem wonderfully liberating, but there's a reason FrontPage stops you from editing such content: The next time FrontPage updates all pages using that template or theme, it will overwrite any changes you've made to areas that the template or theme supposedly controls.

The best advice is to tread carefully when using such components, or to avoid them completely. For example, use ASP.NET user controls rather than Include Page components or Dynamic Web Templates, and use shared style sheet files rather than FrontPage themes.

Selecting the FrontPage or Visual Studio .NET Publishing Model

Visual Studio has a Copy Project command that serves much the same purpose as the Publish command in FrontPage. The Copy Project command, however, has much different options. If you want Visual Studio to copy an ASP.NET project from one location to another, proceed as follows:

1. Open the ASP.NET project in Visual Studio.

2. Choose Copy Project from the Project menu. This displays the Copy Project dialog box, shown in Figure 43-9.

   

   Figure 43-9. The settings in this dialog box control the way Visual Studio copies a project from one location to another.

3. Use the Destination Project Folder box to specify the target of the copy operation. You can enter this location either by typing or by clicking the ellipsis (. . .) button to the right of the text box.

4. Choose a Web access method. The possibilities are:

   • FrontPage Select this option to publish the files though the FrontPage Server Extensions.
   • File Share Select this option to copy the files to a local disk or network file sharing location. Then, in the Path box, enter the location that corresponds to the Destination Project Folder location you specified in step 3.

5. In the Copy section, select which files you want to copy. Here are the possibilities:

   • Only Files Needed To Run This Application Select this option to copy compilation output such as DLLs and references from the bin folder, plus any files that have a Build Action property of Content.
   • All Project Files Select this option to copy compilation output and all files in the project. This copies the same files as the previous option, plus the project file and all source files.
   • All Files In The Source Project Folder Select this option to copy all files in the project folder tree.

6. Click OK to initiate the copy operation.

Interpreting Build Action Values

The Build Action property indicates what Visual Studio .NET does with a file when you build (that is, compile) a project. To view or modify a file's current Build Action property, select the file in Solution Explorer, and then, in the Properties window, scroll down to the entry titled Build Action. Here are the possible values:

• **None **   The file requires no compilation and needn't be present for the project to run. A text file that contains only documentation would have this value.
• **Compile **   The file requires compilation but needn't be present for the project to run. Source code files typically have this value.
• **Content **   The file requires no compilation, but must be present for the project to run. Web pages typically have this value.
• **EmbeddedResource    **The file becomes part of the project build output as a DLL or an executable. Resource files usually have this value.

The default Build Action for a file depends on its file extension.

The Visual Studio Copy Project command behaves like a normal Windows Copy command, and not like a FrontPage Publish command. It doesn't compare date stamps on the source and destination files for example, and it doesn't delete files in the target folder that don't exist on the source. It does, however, prompt before overwriting any files.

The FrontPage Publish command, on the other hand, supports not only the FrontPage and file sharing connections, but also FTP and WebDAV access. It's also more intelligent with regard to incremental file publishing and detecting file conflicts. To take advantage of these features but not publish source code:

1. Display the site's content in a FrontPage All Files report.
2. Sort the All Files report on file extension.
3. Select all files having the extensions .vb, .cs, .resx, .vbproj, and .csproj.
4. Right-click the selection and choose Don't Publish from the shortcut menu.

In Summary. . .

This chapter explained how programmers using Visual Studio and designers using FrontPage can work on the same physical copy of a Web site. These two programs take a markedly different view of Web site development, but with care, you can take the best advantage of each.