Visual Studio .NET is a container environment that integrates the functionality of multiple visual designers. You have a designer for building Windows Forms applications, one for building ASP.NET sites, one for building Web services, and so on. All items required by your work such as references, connectors to data sources, folders, and files are grouped at two levels: solutions and projects. A solution container contains multiple projects, whereas a project container typically stores multiple items. Using these containers, you manage settings for your solution as a whole or for individual projects. Each item in the project displays its own set of properties through a secondary window the Properties window.
Before we meet Visual Studio .NET 2005 in person, let's briefly review the major shortcomings of its predecessor. In this way, you can enjoy the new set of features even more.
Visual Studio .NET 2003 Common Gripes
As you probably know from your own experiences, Visual Studio .NET 2003 has a single model for designing applications: the project-based approach. Real-world experience has shown this is not necessarily the best approach at least as far as ASP.NET and Web applications are concerned.
The project is the logical entity that originates any type of .NET application be it Windows Forms, the Web, a console, or a Web service. Developers build an application by creating a new project, configuring it, and then adding items such as pages, resources, classes, controls, and whatever else will help. For Web applications, a Visual Studio .NET project poses a few issues at two levels at least: machine and integrated development environment (IDE).
Constraints at the Machine Level
For Visual Studio .NET 2003 to run successfully on a development machine, you need to install Microsoft FrontPage Server Extensions (FPSE). FPSE are the only supported way to get to the files of the project, as Visual Studio .NET does not support FTP or even direct Internet Information Server (IIS) access. Among other things, an FPSE-equipped machine runs into trouble as soon as you try to install Windows SharePoint Services (WSS) on it. Additional setup work is required if you want Visual Studio .NET and ASP.NET to work on the same development machine along with WSS test sites.
Visual Studio .NET is dependent on IIS, which must be installed on the same development machine or on a connected server. In addition, each application you create must be tied to an IIS virtual folder. These limitations have a much greater impact on the development process than one might think at first. For example, developers need administrative privileges to create new projects, and effective corporate security policies for developer machines should be defined throughout the company. Furthermore, debugging various configurations and scenarios is definitely hard and challenging, though certainly not impossible.
Constraints at the IDE Level
All in all, the number-one issue with Visual Studio .NET_driven Web development is the tool's inability to open a single ASP.NET page outside of a project. You can open and edit an .aspx page, but Microsoft IntelliSense won't work on it; the same happens with other key features, such as running and debugging the page. Frankly, in this type of scenario Visual Studio .NET 2003 offers only one advantage over Notepad HTML syntax coloring.
In Visual Studio .NET 2003, the project file is the single point of management for the constituent elements of the application. As a result, to make a file part of the project, you must explicitly add it into the project file and configure it you can't just point at an existing virtual directory and go. The information coded in the project file counts more than the actual contents of the directory. As a result, more often than not useless files are forgotten and left around the site. Synchronizing hundreds of files in large applications is not easy; deploying projects onto other machines can be even more annoying.
This model is problematic also from the source control perspective. When managing Web projects under source control, you should perform all available source control operations using Visual Studio .NET. In addition, you shouldn't manually force a file to be under source control. All files that should be source-controlled are placed there automatically when you use the appropriate menu commands. In other words, the project file ends up being the single point of contention with source control.
Visual Studio .NET also does all that it can to force you to use a code-behind class for each page added to the project. In general, keeping code (.cs or .vb file) separated from layout (.aspx file) is a good and highly recommended practice. However, the Visual Studio .NET 2003 implementation of this feature injects a lot of tool-generated code in the project files. This leads to a brittle model of keeping file and control references in sync. Furthermore, the contents of a project are compiled down to single assembly, with the subsequent creation of a single contention point for shared projects, an application's domain restart on every change, and a significantly expensive (and explicitly requested) compile step for large projects.
Finally, you find no support in Visual Studio .NET 2003 for declarative resources and you must perform an explicit code-generation step for adding resources such as WSDL and XSD files.
To sum it up in one sentence: although developers successfully use Visual Studio .NET 2003 for real-world applications, the tool isn't ideal for simpler projects and still has a number of shortcomings.
Visual Studio .NET 2005 Highlights
Visual Studio .NET 2005 provides a simpler and more friendly way to create ASP.NET applications. The key improvements remedy the shortcomings detailed earlier. Let's outline these features briefly. We'll go into more detail later in the chapter as we develop a start-up project.
No IIS Dependency
IIS is no longer a strict requirement for Visual Studio .NET to work.Visual Studio .NET 2005 ships, in fact, with a local Web server that makes IIS optional, at least for quick testing and debugging purposes. Figure 2-1 shows the user interface of the embedded Web server.
Figure 2-1: The local Web server in action in Visual Studio .NET 2005.
The embedded Web server is a revisited version of Cassini, the free mini-Web server that originally shipped with Web Matrix a community-supported, free editor designed for ASP.NET applications. It is important to note that the local Web server represents only the default option. If you open the project from an existing IIS virtual directory, Visual Studio .NET would use IIS to test the application.
The embedded Web server is only a small piece of executable code and can't replace all the features of a full-blown Web server such as IIS. It works only with individual pages and doesn't include any of the extra features of IIS, such as the metabase.
Ways to Access Web Sites
Visual Studio .NET 2005 supports multiple ways to open Web sites. In addition to using FPSE, you can access your source files by using FTP or a direct file system path. You can also directly access the local installation of IIS, browse the existing hierarchy of virtual directories, and access existing virtual roots or create new ones. As Figure 2-2 demonstrates, you can open your Web site using a file system path or an IIS virtual directory. In the former case, the local Web server is used to test the site.
Figure 2-2: The ASP.NET application is controlled by the local Web server if the Web site is opened from a file system path.
The interaction with IIS is greatly simplified, as Figure 2-3 shows. When you try to open a Web site, you are given a few options to choose from. You can locate a project by using a file system path, using the IIS hierarchy of virtual directories (only the local IIS), using FTP, or by just typing the URL of the site configured with FrontPage Server Extensions. The IIS tab also contains buttons to create new virtual roots and applications.
Figure 2-3: Navigating your way through the IIS hierarchy to locate an existing virtual directory to open.
Note
You can open existing Web sites using the FTP protocol and then create and edit files. However, you must have access to the FTP server and read and write permissions for a particular FTP directory. The directory must already exist because Visual Studio .NET 2005 cannot create a new Web site via FTP.
Building the Project Output
Visual Studio .NET 2005 does not compile everything in the site into a single assembly, as Visual Studio .NET 2003 does. Instead, it builds on the new ASP.NET compilation model and dynamically recognizes file types based on the folder they belong to. In this way, not only are changes to .aspx files immediately caught, but so are those made to constituent .cs or .vb files and a variety of accessory resource files. This results in a sort of dynamic compilation for code-behind classes.
There are pros and cons about the new ASP.NET 2.0 compilation model, and some additional parameters need to be considered thoroughly before one can come to a reasonable conclusion about the model. Whatever your final assessment is, though, two facts remain set in stone. First, the ASP.NET 2.0 compilation model allows you to deploy more types of source files (for example, C# and VB.NET classes), monitors these source files for changes, and automatically recompiles. Second, this behavior is optional. If you cringe at the idea of leaving valuable C# source files on the Web potentially at the mercy of hackers, you should just stick to the old model and compile external classes into a separate assembly through an explicit compile step. Whatever your position on the matter is, ASP.NET 2.0 and Visual Studio .NET 2005 give you an alternative.
Solution files (*.sln) are supported, but they're no longer necessary for creating and managing a Web project. The root Web directory defines a Web project; you just add files to the directory and they are in the project. If a file doesn't immediately show up, you right-click on the Solution Explorer window and select Refresh Folder. Solution files are still useful to manage multiple projects, but they don't need to live in the Web directory.
Copying a Web Project
Another long-awaited feature worth a mention is the Copy Web site feature. In earlier versions of Visual Studio .NET, duplicating and synchronizing a Web project onto another machine, or simply moving it to another location within the same machine, was not a hassle-free task. Basically, it was completely up to you and to any FTP-based tool you could come up with. If your server host supported FPSE, you could go through the Visual Studio .NET 2003 integrated wizard the Project|Copy function. Otherwise, the most viable solution was using raw File Transfer Protocol (FTP). (Moving a Web site within the same network or machine is a similar experience, except that you can use Windows Explorer.)
Sure the overall procedure was not smooth; but it was hardly a mission-impossible task because only a brute-force copy is required. But what if, with good reason, you wanted to move modified files only? Or only files that match given criteria? In these cases, you were left alone to find and copy only these files. (On the other hand, I'd say, who's better qualified than you for this kind of task?)
In Visual Studio .NET 2005, by selecting a menu item you can copy your current Web site to another local or remote location. The Copy Web Site function is a sort of integrated FTP tool that enables you to easily move files around. Figure 2-4 shows a glimpse of the feature.
Figure 2-4: The Copy Web Site feature in action.
You connect to the target destination, select the desired copy mode either Overwrite Source To Target Files, Target To Source Files, or Sync Up Source And Target Projects and then proceed with the physical copying of files. As Figure 2-5 shows, you can copy files to and from virtual and physical folders, within or across the machine's boundaries.
Figure 2-5: Connecting to a remote site to make a copy of the local project.
As you can see yourself, the Copy Web Site function is ideal for deployment especially in hosting environment scenarios in which you need to manage live server files. In addition, the Visual Studio .NET 2005 tool can operate as a synchronization tool, which is helpful to quickly test applications in different scenarios and configurations.
Smarter Editing with IntelliSense
Last but not least, Visual Studio .NET 2005 supports standalone file editing and doesn't require a project to edit a single file on disk. So if you double-click an .aspx file in Windows Explorer, Visual Studio .NET 2005 starts up and lets you edit the source code. Unlike with the previous version, IntelliSense and related syntax-coloring work effectively. The page can be viewed live in the embedded browser through the local Web server.
Note that IntelliSense now works everywhere within the source file (see Figure 2-6), including within data-binding expressions, page directives, and code inline in .aspx files.
Figure 2-6: IntelliSense works everywhere around the source code of the page.
In Visual Studio .NET 2003, IntelliSense support in the HTML view of the page was hard to achieve for custom controls. Basically, you had to create an XSD file manually to describe the public interface of a control; next, you had to install that file in a particular folder and link it to the page through an xmlns attribute. Thankfully, you should never have to author this schema file manually in Visual Studio .NET 2005. A valid schema file is automatically generated when the page author first drops the control on the page. The schema generator does its job after looking at any metadata associated with the controls. However, no new metadata attributes are used. The schema generator grabs all that it needs out of existing attributes used for declaring expected parsing and persistence behavior for controls. (See the "Resources" section at the end of this chapter.)
Important
In light of this, if you are authoring custom controls for ASP.NET 2.0 be sure to check how IntelliSense works for your control in Visual Studio .NET 2005. You can do a lot to ensure that IntelliSense works appropriately by applying the appropriate metadata to controls.
