What's New in Web Projects
This topic describes how the organization and structure of Web sites have changed from earlier versions of Microsoft Visual Studio.
In Visual Studio .NET 2002 and Visual Studio .NET 2003, Web projects were organized using essentially the same model that was used for client projects (Windows Forms projects). The Web project was based on a model in which the entire project was compiled into a single executable assembly.
In Visual Web Developer, the organization of Web projects has been changed to reflect more accurately the way ASP.NET applications are typically constructed. This topic describes the changes at a high level and provides links to topics that describe new and changed features in more detail.
Types of Web Sites
A significant difference is that you can now create different types of Web sites. Instead of creating only Web sites that run as Internet Information Services (IIS) applications, you can now create the following types:
File-system Web site You can store files in any folder, and you can open and work with any collection of Web pages, no matter where they are located. An important feature is that you do not need to have IIS installed to run pages in a file-system Web site. Instead, you can test your Web sites by using the ASP.NET Development Server, a lightweight test server. For details, see.
FTP Web site You can open and edit Web site files by using the File Transfer Protocol (FTP) directly from within Visual Web Developer.
Local IIS Web site You can continue to create Web sites that run under your local copy of IIS, as you did in earlier versions of Visual Studio. Local IIS Web sites do not require FrontPage Server Extensions.
Remote Web site You can create Web sites that run under IIS on a different computer that is running either FrontPage 2000 Server Extensions or FrontPage 2002 Server Extensions. For more information, see.
Web Site Layout
As in earlier versions of Visual Studio, you keep your Web pages in the root of the Web site and in subfolders, as required by your application. However, your Visual Web Developer Web site can contain the following subfolders that have specific characteristics:
App_Browsers folder Contains browser definition files that ASP.NET uses to identify individual browsers and determine their capabilities.
App_Data folder Contains Microsoft Access databases (.mdb files), XML files, and other data stored in local files. The user account that is used to run the application (for example, the local ASPNET account) has permissions to read, write, and create files in this folder. Various ASP.NET application features, such as the providers for membership and roles, as well as the Web Site Administration Tool, are configured to work with the App_Data folder specifically.
Bin folder Contains compiled code, as in earlier versions of Visual Studio. Any classes represented by code in the Bin folder are automatically referenced in your Web site. For more information, see.
App_LocalResources folder Contains .resx files that are bound to a specific page. You can define multiple .resx files for each page, each .resx file representing a different language or language/culture combination. For more information, seeand .
App_GlobalResource folder Like the App_LocalResources folders, but contains .resx files that are not bound to a specific page. Resource values in .resx files in the App_GlobalResource folders can be accessed programmatically from application code.
App_Code folder Contains source code files. The code is compiled as part of your application and is referenced automatically. The App_Code folder works much like the Bin folder, except that you can put source code in it instead of compiled code. While you are working in Visual Web Developer, the source code in the App_Code folder is compiled dynamically so that IntelliSense can reference any classes defined in the files. For more information, see.
App_Themes folder Contains a collection of files that define the appearance of ASP.NET Web pages and controls. For more information, see.
App_Browsers folder Contains .browser files that define browser capabilities.
App_WebReferences folder Contains files used to create a reference to a Web service (in the same project or external to the project), including .disco and .wsdl files. For more information, see.
Visual Web Developer does not create these folders by default, except the App_Data folder. In some cases, the folders are created by utilities. For example, running the Generate Local Resource command creates the App_LocalResources folder. In other cases, you can create the folders manually.
Simplified Web Site Templates
When you create a new Web site, the number of files that are created by default is less than it was in earlier versions of Visual Studio. In general, Visual Web Developer creates only the files that you need. As a consequence, a Web site does not initially contain a Web.config file, a Global.asax file, and so on. If you need these files in your Web application, you can add them as new items. Similarly, although ASP.NET treats certain folders specially, the folders are not created by default. Similarly, you can add any additional folders that are required by your application.
Changes in Code-Behind and Single-File Page Models
ASP.NET version 2.0 features a new code-behind model that simplifies the relationship between the .aspx page and its corresponding code. Visual Web Developer also includes complete support for single-file pages. For details, seeand .
Changed Build and Deployment Model
In earlier versions of Visual Studio, Visual Studio would build (or compile) your Web site project into a single assembly when you ran a page. In the new project model, you do not need to compile your project before running it. Visual Web Developer now follows the model supported by ASP.NET — pages and their dependent components are compiled individually when they are requested, and the compiled version of the page is cached until the source is changed.
By default, Visual Web Developer builds your Web site each time you test it by running it from the designer, and you can explicitly build individual pages or the entire Web site at any time. The purpose of this build process is to help you find compile-time errors, not to produce executable code. The output of this build step is discarded after the build process, and the request compiles the page as normal.
The change in build models means that you do not deploy your site by copying a single .dll file and supporting .aspx files. Instead, you copy the entire site, including .aspx files, class files (.vb, .cs, or .jsl files), and other files, all as source files. Deploying sites by copying the source simplifies deployment (because you do not need to copy binary files) and maintenance (because you do not need to recompile the entire site whenever you make a change in a class file).
Visual Web Developer offers several deployment options. You can publish your site, which precompiles the site and then copies the output to a target location. Precompiling for publishing performs the same compilation that would normally occur dynamically at run time, producing binary output. You can precompile the site and replace the .aspx files in your site with stubs that point to the compiled versions of the pages. Alternatively, you can publish the site as an updateable site, which does not compile the .aspx files into stubs, and therefore allows you to change markup and layout without recompiling and republishing. As with building your project in Visual Studio .NET 2003, precompiling helps you catch compilation errors, and because dynamic compilation is not required, precompiling can help reduce the startup time for your site. An important feature of precompiling for publishing is that it can also help protect your site's source code by providing you with an object-only version of the site that you can deploy.
The Publish Web Site utility is not available in Visual Web Developer Express Edition.
An alternative to publishing your site by precompiling it is to copy your site to the production server using the Copy Web tool. The Copy Web tool works like an FTP utility, allowing you to copy files to and from a target site and providing the option to synchronize two sites automatically.
For more information, see.
As with Visual Studio .NET 2002, you can create the code for Web pages in a variety of the .NET Framework languages. Because the Web site is not compiled into a single assembly, you can have pages and components that use different programming languages in the same Web site.
Web Server Requirements
You no longer need IIS to test your Web projects. Visual Web Developer includes the ASP.NET Development Server, a Web server that runs on your local computer and can serve (or run) pages. The ASP.NET Development Server accepts requests only from the local computer (localhost), and is therefore both convenient for testing pages on your computer and protected against requests from outside of your computer.
If you create a file-system Web site, when you run your project in Visual Web Developer, Visual Web Developer starts the ASP.NET Development Server and displays the page. (If you are working with a local IIS site, remote site, or an FTP site, Visual Web Developer runs the page by using the version of IIS that is associated with that Web site.)
Project Information Persistence
Visual Web Developer no longer requires a project (.vbproj or .csproj) file for Web sites. A significant benefit of not having a project file is that the site is easier to develop with multiple programmers, since there is no contention for a central project file. In addition, you can open any folder containing Web files as a Web site.
Because Web sites are now file-system based, one of the primary purposes of the project file — to track which files belonged to the project — is no longer necessary. Other information that was tracked in a project file is now stored in the Web.config file. For more information, see.
Web sites continue to use solution (.sln and .suo) files to track user-specific configuration information for the site. Visual Web Developer also maintains user-specific information, such as debug information, in the local user folders. For more information, see.