LANGUAGES: C#, J#, VB .NET
ASP.NET VERSIONS: 2.0
Big Changes in VS .NET
If you're expecting a minor upgrade of Visual Studio, you're in for a surprise.
By Michiel van Otegem
When I first installed Visual Studio "Whidbey," my reaction was the same as with the previous versions: I was irritated at the long installation time. Once Visual Studio was installed, though, my irritation changed to excitement. Visual Studio has gotten a good makeover. Lessons learned from previous versions, as well as from ASP.NET Web Matrix, have found their way into the product.
One of the first things I noticed was that I had to choose the type of development environment during the installation. This is different from the previous versions, in which you could adjust the environment to reflect the type of developer you are upon starting Visual Studio, making this new version of VS .NET much less overwhelming by hiding options you're not likely to use.
Being an ASP.NET Web Matrix fan, I immediately felt at home because the IDE for Web developers feels much like the IDE of Web Matrix. Like Web Matrix, the windows open by default are the Toolbox, Solution Explorer, and Properties windows. That said, Visual Studio Whidbey is immensely more powerful than ASP.NET Web Matrix, and the user interface is much more sophisticated. As you would expect from any Visual Studio product, the IDE is highly customizable, with all the windows allowing docking and undocking, auto hiding, and pinning, as well as combining windows into one window with tabs. I found that this works smoother than in the 2003 version and, in addition, is helped by "guides" that pop up when you drag a window (as shown in Figure 1).
Figure 1. Dragging windows shows guides that help you set up the IDE the way you want it.
When you hover the mouse over a particular guide, the action of that guide is previewed using the dark blue frame. So, hovering over the guide shown at the bottom of Figure 1 would show the window docked at the bottom of the screen. If you released the mouse at that point, the window would take the place of the preview. The guides and preview mechanism work like a charm, and I actually was able to set up the IDE to my liking in one go, whereas with previous versions, I never really got the hang of it and ended up leaving it in the default setup.
The simplicity of the IDE enables developers to get up and running quickly, but there are a number of windows and toolbars you can add if you like to have more power directly at your fingertips. These include a Data Explorer for database connections, an object browser, and a task list, among others.
The code editor provides three different views for pages and user controls: Design, Source, and Server Code. In Design view, you get a designer similar to the current version of Visual Studio, and in Source view, you get the source of the current page, including the server script code if you're using inline code instead of code behind. When you open a file, you get the Source view by default. If you prefer Design view as the default (as is the case with the current version and Web Matrix), you can change this through the application options. In Server Code view you see only the inline server code, without the surrounding script tags. If you're using code-behind, this view is not available. Instead, the code-behind file is shown in a separate window. Code-behind is used by default, but you can change this to inline code. This is much better supported than it is in the 2002 and 2003 versions of Visual Studio, in which you had to manually remove the code-behind file and the code associating code-behind with a page.
If you usually put code in code-behind files for security reasons, you might think that inline code is a bad idea. However, the next version of ASP.NET supports several new deployment methods with source-code protection. This makes the choice between inline code and code-behind much more of a personal preference, unless you create multiple pages based on the same code-behind file. The coupling between the code-behind file and the page file is looser than previous versions of Visual Studio; this is reflected in the changes to the Page directive for code-behind. The code-behind attributes are now CompileWith and ClassName. From a code perspective it is also much cleaner, because code-behind is implemented using a new feature known as partial classes. Partial classes allow you to have more than one code file for a class, and this is exactly what code-behind is all about. In the previous version the .aspx file inherits the class defined in the code-behind file, which is much less elegant.
As you would expect, IntelliSense works fine, even with inline code. This is actually more significant than you would imagine, considering it didn't work with inline code in previous versions (because of some architectural constraints). Because inline code is now the default, though, it was important to get this to work. IntelliSense also works with Page directives, which is a great plus. IntelliSense for web.config is not supported yet, but because that's a much-requested feature, it may find its way into Visual Studio Whidbey by the time the product ships. In Design view, there's an addition I would also classify as IntelliSense (see Figure 2). When you insert a server control or select it, the designer shows common tasks for that specific control. For a repeater, for instance, you can pick "Connect To DataSource ...", and for a SqlDataSource, you can choose "Configure DataSource ...". In previous releases, you would have to right-click the control for some of these options.
Figure 2. IntelliSense in Design view tells you what you can or need to do with a specific control. Many of the options start some kind of wizard to walk you through the process.
A major change to the editor is one at the top of many developers' lists: being able to switch views without Visual Studio changing your code or HTML. Changes to the HTML made by the current version of Visual Studio, as well as Web Matrix, drive developers close to insanity. In Whidbey, the HTML is validated against the given schema, but is never changed. Even if you add new elements in Design mode, the surrounding code is not affected. Validation of HTML is greatly improved, also, and now includes schemas for Internet Explorer 3.02 and Netscape Navigator 3.0, Netscape 4.0, several XHTML options, and mobile HTML. This makes for much easier development toward a specific browser platform. Another feature that has great benefits when switching between views is the preservation of a selection. If you select a control in Design view, that same control is selected in Server Code view, and vice versa. This means you never have to go looking for some item you selected after switching from one view to another.
For pure code files, the editor also offers some basic refactoring functionality, so you can make changes to code easily and speed up development (see Figure 3). This can go from inserting a simple "if" statement to helping you leverage interfaces. If you insert some code - if you surround a block of code with an if statement, for instance - Visual Studio inserts a skeleton that it then highlights. The highlighted code also shows a tool tip indicating how you should change the inserted code, as you can see in Figure 3. The refactoring functionality is only available for C#. C# development is viewed as more code-centric than VB .NET, for instance, so this makes sense.
Figure 3A. The refactoring tools allow for quick code changes. Visual Studio provides a refactoring menu and shows a tool tip for any code you insert.
Figure 3B. The refactoring tools allow for quick code changes. Visual Studio provides a refactoring menu and shows a tool tip for any code you insert.
Projects and the Toolbox
Web projects in Visual Studio Whidbey don't have any project or solution files. Instead, a folder is the basis for a project. This is much easier when you create projects, and it's even better when you have to open existing projects. Just point Visual Studio to the right folder, and you're good to go. This means you also can copy project files to another machine easily, without Visual Studio nagging that it can't find the associated solution for the project you're trying to open. This is possible because sites on the local hard drive are not run by Internet Information Server by default, but by an internal Web server that comes with Visual Studio. This Web server is purely for development purposes, so it serves requests from localhost exclusively, for security reasons. Projects are not restricted to folders on the local hard drive (or share). You can create new projects or open existing projects through FTP, SharePoint, or Source Safe just as easily.
When creating a new project, you can currently choose from several options. Besides an empty Web site, the most important choices are an Internet site and an intranet site. The Internet site template provides a fully functional site with functionality common to Internet sites. It includes an articles section and a picture gallery and provides authentication and authorization. The site uses master pages for a uniform look and feel, and the data for the Internet site comes from two Microsoft Access database files and an XML file store in the Data folder of the Web site. The intranet template shown in Figure 4 provides a fully functional intranet. In a sense, it's not much different from the Internet template, but besides using and demonstrating authentication, authorization, and master pages, it also uses other features, such as personalization with Web parts, and data-bound navigation.
Figure 4. The intranet template provides a fully functional intranet Web site. The main page of this site shows that it uses master pages, data-bound navigation, and personalization.
The toolbox for ASP.NET development has been enhanced greatly. It has a section with core controls that mainly correspond to the ASP.NET controls available in version 1.1. Other controls, such as those for personalization and navigation, all have their own sections in the toolbox, as you can see in Figure 5.
Figure 5. The toolbox contains additional sections for personalization, security, validation, and navigation. This is needed because the toolbox can contain tens or even hundreds of controls.
The toolbox is customizable, of course, and supports adding your own controls as well as code snippets. You also can add controls through the Control Gallery shown in Figure 6. The Control Gallery is an online community repository for controls you can use in your projects. When you select and add a control, it is automatically downloaded and installed, and it shows up in your toolbox.
Figure 6. You can add third-party controls to the toolbox easily. One option is to use the Control Gallery to get controls from community sites.
The debugging support is enhanced yet again in Visual Studio Whidbey. Where the 2003 version already added some support for edit-and-continue debugging, Whidbey actually makes this work properly. For Web development, this still means that after you make a change, you must refresh the browser, but the experience is smoother than in previous versions. Whidbey also provides more information during the debugging process, in particular through a better implementation of DataTips, which are already available in the current version of Visual Studio. DataTips provide information about variables, expressions, and the like during the debugging process. There are some other added features, but, unfortunately, these are not well-documented at this point. These include advanced debugging with breakpoints on disassembly, registers, and addresses (when applicable), and "Just My Code Stepping."
As mentioned earlier, you can use Visual SourceSafe to store applications under source control. Because Visual Studio Whidbey comes with Visual SourceSafe 2004, a new version of Microsoft's source-control software, this is a logical choice. Source control isn't limited to SourceSafe, though, and you actually can integrate another source-control product into Visual Studio through the Options menu. All you need to do is make sure your source-control product provides a plug-in to integrate with Visual Studio.
Visual Studio Whidbey is a huge step forward in usability and productivity. Many of the problems that exist in Visual Studio 2003 (or ASP.NET Web Matrix), have been dealt with in Whidbey. The IDE and features such as IntelliSense are much better, not the least of which is that IntelliSense works perfectly in files with both code and HTML. I think you'll find that Visual Studio Whidbey is a very productive tool.
Michiel van Otegem (mailto:[email protected]) is the software architect for The Vision Web, a solution provider based in the Netherlands. He is also an author and speaker, the co-founder of http://www.ASPNL.com, and president of the Dutch .NET user group dotNED. For his community efforts, Michiel has received the Microsoft Most Valuable Professional award.