Visual Studio .NET Whidbey

Visual Studio .NET "Whidbey"

You may wonder about the confusion over development tools and which tool a developer should use for which purpose. After all, no matter what type of development is being done, many of the requirements are the same. However, there are differences in the ways developers work in different types of applications, especially Web applications. To understand those differences you have to look at both the history of ASP development and the current tools. ASP rapidly rose to success, with a very diverse set of developers, ranging from corporate teams to home hobbyists. Despite its widespread use there was no dedicated development tool. There were plenty of editors with which ASP could work (Visual InterDev, Front Page, and so on), but nothing specific. Visual Studio was purely a Windows development tool.

With the release of .NET 1.0, Visual Studio became Visual Studio .NET and was enhanced to allow Web development. The real trouble with this approach wasn't with Visual Studio .NET itself but more with the completely different way of working from that previously used by most ASP developers. For example, the code-behind model was alien to ASP scripters, who were used to having all of their code within the same file, and the whole idea of a project didn't relate well with people who were used to just dealing with files in a directory.

Another issue was that Visual Studio .NET is a professional development tool and therefore commands a professional price. A large amount of Web development is done by amateurs, for whom the price of this tool is too high. Enter Web Matrix, a small, easy-to-use, and (most importantly) free development tool. Web Matrix is aimed only at ASP.NET developers and also has become a test bed for new ideas and features that weren't in Visual Studio .NET. There wasn't a tool that had everything a developer neededuntil now.

The latest version, Visual Studio .NET "Whidbey," is not only a combination of the best bits of both Visual Studio .NET 2003 and Web Matrix but also the next step upward. Along with great design features such as support for drag and drop, Visual Studio .NET "Whidbey" also brings the following benefits.

• There are no project files, thus existing sites can simply be opened from their locations.

• Support for code in-line, or the new code-separation model, allows files created with other editors to be easily imported.

• Multiple ways to access Web sites, such as through the file system, IIS, FTP, and SharePoint, are available.

• The Data Explorer integrates a data editing tool and allows drag and drop of tables onto the design grid.

• Support for the new data binding models allows easy design of data-driven pages.

• Visual inheritance with master pages eases site design.

• Full IntelliSense in HTML and code views enables quicker code development.

• A built-in Web Server allows development and testing without IIS.

• The ability to import and export user settings allows you to easily configure other installations of Visual Studio .NET "Whidbey" with your favorite preferences.

• Sample projects help developers create out-of-the-box sites with little or no extra work required.

In this chapter we'll look at some of these features and see how some of the new architectural changes to ASP.NET integrate with Visual Studio .NET "Whidbey" and make development easier.

Project-less Development

There are two very good reasons why moving to a project-less system is a good choice. First, it makes team development simpler. For teams using a source code control system the project file becomes a blocking point. All files checked into and out of the project require the project file to be checked in and out. With multiple people editing multiple files, the project file can easily be locked by another person. Second, a project-less system is easier for sites designed with other development toolsthe absence of a project system means sites can be easily accessed directly. For example, Figure 2.1 shows the Open Web Site dialog when selecting FTP as the mechanism.

Figure 2.1. Opening a Web site via FTP

If an existing site was not created with Visual Studio .NET "Whidbey," it will be upgraded in place, so be careful if you plan to open existing Web sites. (You will see a warning.) Whichever method of opening a site you use, or when creating new sites, you will see a familiar layout (Figure 2.2).

Figure 2.2. The Visual Studio .NET "Whidbey" main windows

Although this is a new tool you can see it looks very similar to both Visual Studio .NET 1.0/2003 and Web Matrix, thus ensuring that developers can work in a familiar environment. When you work within it, though, you will soon realize that there are many more features.

The Solution Explorer

The Solution Explorer is almost the same as in previous versions of Visual Studio .NET, although it has been simplified. There are no longer two buttons for opening Web pages, one for design view and one for code view. (How often did you double-click to open the file only to have it open in design view rather than code view?) Visual Studio .NET "Whidbey" supports both in-line code and the new code-separation model, where files show in the Solution Explorer as two files (Figure 2.3).

Figure 2.3. The Solution Explorer

Here you can see that both the user-interface (UI) file and the code-behind file are separate items. Double-clicking opens the file in the design window.

The Toolbox

The Toolbox is the same as in previous versions of Visual Studio .NET, although there are more tabs, with controls split into logical groups:

• Core, for the core server controls such as TextBox , Label , and so on

• Data, for the DataSource and grid controls

• Personalization, for the WebPart controls

• Security, for the login controls

• Validation, for the field validator controls

• Navigation, for navigation controls, such as SiteMapPath

• HTML, for the HTML controls

Of course, the Toolbox is customizable, not only by adding local components but also by adding components from Web sites by use of the Control Gallery, as shown in Figure 2.4. This means that it's going to become easier to find additional components .

Figure 2.4. Adding components from the Control Gallery

The Design Window

The design window is similar to that in previous versions of Visual Studio .NET, although there are a number of important differences. The first thing to note is that the default layout mode is flow, not absolute; the second is the different views you get within the editor. Figure 2.5 shows the design window with two files open: Authors.aspx and its associated code-behind file, Authors.aspx.vb .

Figure 2.5. The design window

At the bottom of this window there are three buttons to switch between the design view, the entire source view, and the code view. All three of these apply to the same file but show a different view.

• Design is the standard design surface.

• Source is the entire source code for the file, including the UI section and in-line code.

• Server Code is just the in-line code.

It is important to realize that ASP.NET pages can have code both in-line and in the code-behind file, as seen in Figure 2.5, although it's best to keep code in one location only. Here there is a Page_Load event in-line with the server control, and yet there is also a code-behind file. For code-behind files, creating an event with Visual Studio .NET "Whidbey" (either by double-clicking or from the Properties window) for a control with a code-behind file will switch to the code-behind file and create the event procedure there. For code-in-line files, the event procedure will be created in-line. We'll look at the structure of this in more detail later in the chapter.

Another addition to the source view is that the Toolbox isn't disabled because drag and drop is fully supported in the source editor. This prevents having to switch to the design view to add new controlsthey can simply be dragged from the Toolbox and dropped into the source file. Better support for the code editor has also been provided by enabling the Properties window to track the cursor so that the properties reflect the object the cursor is currently on. Both of these features are attractive to developers who prefer to work in source view rather than design view.

The Design Surface

The design surface works exactly the same as in previous versions of Visual Studio .NET except that it's more context sensitive (e.g., the right-mouse click generally has more features) and supports common tasks for many controls. For example, consider Figure 2.6, where a GridView has been added to the page. Selecting the GridView shows an additional icon, like a SmartTag in Office.

Figure 2.6. Viewing common tasks for a GridView

Upon selecting this tag, a Common Tasks panel is displayed (Figure 2.7), showing the most common tasks applicable to the object. Some of these are also available from the context menu, thus giving you different ways to set the properties for an object.

Figure 2.7. The GridView common tasks

The Data Explorer

A new feature that comes from Web Matrix is the Data Explorer, which allows connections to data stores to be set up. For example, Figure 2.8 shows a connection to a SQL Server. With the Technology Preview release, the only supported provider from the Data Explorer is OleDb, but future revisions will support all providers.

Figure 2.8. The Data Explorer

Once connected, you have a great range of features to control your data sourcein fact, the Data Explorer is almost a mini SQL Server Enterprise Manager. For example, you can create new objects (including database diagrams and functions), edit existing ones, edit data, export data, and so on. The great advantage of having so much power in the Data Explorer is that you don't have to load an additional tooleverything you need is right within your development environment. In fact, it's better than Enterprise Manager because the stored procedure editor isn't modal!

Another great feature links two windows, allowing you to drag tables from the Data Explorer and drop them onto the design surface. When you do this a DataSource and GridView are automatically created and formatted, as shown in Figure 2.9, where the authors table has been dropped onto the page.

Figure 2.9. A database table dropped onto a page

The SqlDataSource is automatically configured, and the commands used to fetch and update data are populated . To edit the properties of the DataSource control you can select Configure DataSource from the Common Tasks menu, which displays the window shown in Figure 2.10. Here you see the currently selected connection (from the Data Explorer) and the provider details. These cannot be changed here, but if you do need to edit them (e.g., to pick another provider), you can edit the connection details manually in the properties for the DataSource .

Figure 2.10. Configuring a DataSource

Clicking the Next button allows you to edit the SQL statements used to fetch and update data, as shown in Figure 2.11. By default these are built as direct SQL strings, but they can just as easily be stored procedures.

Figure 2.11. Editing DataSource SQL statements

You can fine-tune the commands by selecting the Edit Query link, which displays the window shown in Figure 2.12.

Figure 2.12. Configuring the SELECT command

Here you can edit the query, add parameters, and specify the source of the parameterin this case it's set to the value of a drop-down list. This allows you to easily build commands based on values external to the data source, such as control values, form fields, query string values, and so on. This technique allows you to build powerful pages without any code at all.

Visual Inheritance

In Chapter 1 we briefly looked at how a single site-wide style could be applied to all pages through the use of master pages. Visual Studio .NET "Whidbey" fully supports this model. It allows the creation of master pages and the linking of standard pages to a master, and it shows the visual inheritance of the master. For example, Figure 2.13 shows a master page that defines the menu on the left and the logo and login details along the top.

Figure 2.13. A master page

The important aspect of this page is the ContentPlaceHolder , which defines the area where child pages can add their content, as shown in Figure 2.14. Here all of the content from the master page shows on the screen but is disabled. Thus you can edit content only in the area allowed by the master page.

Figure 2.14. A child page that uses a master

Master pages are covered in more detail in Chapter 5.

Built-in Administration

Administration of Web sites has been improved by building in support for the Web Administration Tool. From the Website toolbar there is an ASP.NET Configuration option, which launches the Web Administration Tool within a window within Visual Studio .NET "Whidbey", allowing you to configure your site without leaving the editor.

This same menu will also have the capability to publish an entire site to a remote location, allowing you to easily work on a local copy and deploy it when ready.