Web Projects

So far, you’ve seen how to create websites without any project files. The advantage of projectless development is that it’s simple and straightforward. When you create a projectless website, you don’t need to deploy any extra support files. Instead, every file in your web folder is automatically considered part of the web application. (This model makes sense because every web page in a virtual directory is independently accessible, whether or not you consider it an official part of your project.)

Projectless development remains popular for the following reasons:

• Projectless development simplifies deployment: You simply need to copy all the files in the website directory to the web server—there aren’t any project or debugging files to avoid.
• Projectless development simplifies file management: If you want to remove a web page, you can simply delete the associated files using the file management tool of your choice. If you want to add a new page or move a page from one website to another, you simply need to copy the files—there’s no need to go through Visual Studio or edit the project file. You can even author web pages with other tools, because there’s no project file to maintain.
• Projectless development simplifies team collaboration: Different people can work independently on different web pages, without needing to lock the project files.
• Projectless development simplifies debugging: When creating a web project, you must recompile the entire application when you change a single page. With projectless development, each page is compiled separately, and the page is only compiled when you request it for the first time.
• Projectless development allows you to mix languages: Because each web page is compiled separately, you’re free to code your pages in different languages. In a web project, you’d be forced to create separate web projects (which is trickier to manage) or separate class library projects.

That said, there are some more specialized reasons that might lead you to adopt project-based development instead, or use web projects in specific scenarios. You’ll consider these in the next section.

Project-Based Development

When you create a web project, Visual Studio generates a number of extra files, including the .csproj and .csproj.user project files and a .sln solution file. When you build your application, Visual Studio generates temporary files, which is places in the Obj subdirectory, and one or more .pdb files (in the Bin subdirectory) with debugging symbols. None of these files should be deployed to the web server when your web application is complete. Furthermore, none of the C# source code files (files with the extension .cs) should be deployed, because Visual Studio precompiles them into a DLL assembly.

Project-based development has a dedicated following. The most significant advantages to web projects are the following:

• The project development system is stricter than projectless development: This is because the project file explicitly lists what files should be part of the project. This allows you to catch potential errors (such as missing files) and even deliberate acts of sabotage (such as unwanted files added by a malicious user).
• Web projects allow for more flexible file management: One example is if you’ve created several separate projects and placed them in subdirectories of the same virtual directory. In this case, the projects are kept separate for development purposes but are in essence the same application for deployment. With projectless development, there’s no way to keep the files in these subdirectories separate.
• Web projects allow for a customizable deployment process: Visual Studio project files work with the MSBuild utility, which allows project compilation to be automated and customized. Also, you get more control over the generated assembly for your web application, which you can name appropriately, sign, and so on.
• Web projects work better in some migration scenarios: For this reason, ASP.NET automatically converts Visual Studio .NET 2003 web projects to Visual Studio 2008 web projects. This conversion requires fewer changes to your pages.

Both projectless and project-based development give you all the same ASP.NET features. Both approaches also offer the same performance. So which option is best when building a new ASP.NET website? There are advocates for both approaches. Officially, Microsoft suggests you use the simpler website model unless there’s a specific reason to use a web project—for example, you’ve developed a custom MSBuild extension, you have a highly automated deployment process in place, you’re migrating an older website created in Visual Studio 2003, or you want to create multiple projects in one directory.

Creating a Web Project

To create a web project, choose File ➤ New ➤ Project to show the New Project dialog box (Figure). Then, in the Project Types tree, browse to Visual C# ➤ Web. Then choose ASP.NET Web Application.

When creating a web project, you supply a location, which can be a file path or a URL that points to a local or remote IIS web server. You also supply a project name, which is used to create a subdirectory (or virtual directory, if you’re using a URL) at the location you’ve chosen. You can change the version of the .NET Framework that you’re targeting using the list in the top-right corner of the window, as you can when creating a projectless website.

Figure. The New Project dialog box

Although web projects and projectless websites have the same end result once they’re deployed to the web server and compiled, there are some differences in the way they’re structured at design time. These differences include the following:

• Compilation: As explained earlier, web projects are compiled by Visual Studio (not ASP.NET) when you run them. The web page classes are combined into a single assembly that has the name of the web project (like WebApplication1.dll), which is then placed in the Bin folder.
• Code-behind: The web pages in a web project always use the code-behind model. However, they include an extra file with the extension .aspx.desginer.cs, which includes the declarations for all the controls on the web page. This means if you create a page named Default.aspx, you’ll end up with a code-behind class in a file named Default.aspx.cs and control declarations in a file named Default.aspx.designer.cs (see Figure 2-23). At compile time, these two files will be merged. In a projectless website, you never see a file with the control declarations, because this part of the code is generated at compile time by ASP.NET.
• The Page directive: The web pages in a web project use a slightly different Page directive. Instead of using the CodeFile attribute to indicate the file that has the source code, they use the CodeBehind attribute. This difference is due to the fact that Visual Studio performs the compilation instead of ASP.NET. ASP.NET checks the CodeFile attribute, but Visual Studio uses the CodeBehind attribute.
• Assembly references: In a projectless website, all the assembly references are recorded in the web.config file, so ASP.NET can use them when resolving references at compile time. But the assembly references in a web project are stored in a project file, which Visual Studio uses when it compiles the code. The only exceptions are the references to the System.Core.dll and System.Web.Extensions.dll assemblies, which contain all the features that are specific to .NET 3.5. These references are defined in the web.config file because they include classes that you need to specify new configuration settings.

Migrating a Website from a Previous Version of Visual Studio

If you have an existing ASP.NET web application created with an earlier version Visual Studio, you can migrate it to the ASP.NET world with ease.

If you created a projectless website with Visual Studio 2005, you use the File ➤ Open ➤ Web Site command, just as you would with a website created in Visual Studio 2008. The first time you open a Visual Studio 2005 website, you’ll be asked if you want to adjust it to use ASP.NET 3.5 (see Figure). If you choose Yes, the web.config file will be modified to target .NET 3.5, as described in the “Multitargeting” section earlier in this chapter. If you choose No, your website will continue targeting ASP.NET 2.0, but you can modify this detail at any time by choosing Website ➤ Start Options. Either way, you won’t be asked again, because your preference is recorded in the hidden solution file that’s stored in a user-specific Visual Studio directory.

Figure. Opening a projectless website that was created with Visual Studio 2005

If you created a web project with Visual Studio 2005, Visual Studio 2003, or Visual Studio .NET, you need to use the File ➤ Open ➤ Project/Solution command. When you do, Visual Studio begins the Conversion Wizard. The Conversion Wizard is exceedingly simple. It prompts you to choose whether to create a backup and, if so, where it should be placed (see Figure 2-25). If this is your only copy of the application, a backup is a good idea in case some aspects of your application can’t be converted successfully. Otherwise, you can skip this option.

Figure. Importing a web project that was created with an older version of Visual Studio

When you click Finish, Visual Studio performs an in-place conversion. Any errors and warnings are added to a conversion log, which you can display when the conversion is complete.