A Programmer's Introduction to Visual Studio .NET "Whidbey"
Sean "Early" Campbell
Scott "Adopter" Swigart
3 Leaf
December 2003
Summary: This article examines the top 10 features introduced in the upcoming Whidbey release of Visual Studio .NET. (12 printed pages)
Contents
Overview
The Top 10
Refactoring
Edit and Continue
ClickOnce
Smart Tags
Code Snippets
Exporting IDE Settings
Line Revision Marks
Temporary Projects
Data Inspection Improvements
Docking Window Changes
What About Web Development?
Other Features
Summary
Overview
In this article, you'll learn about the new features of Visual Studio® .NET "Whidbey" and how they can make you more productivity when writing code. Considering the astounding number of new features in the Whidbey release of Visual Studio .NET IDE, we are going to spend our time going through a Top 10, followed by a glance at other features we found exciting.
The Top 10
In our opinion, these are the best features introduced in Visual Studio .NET Whidbey:
- Refactoring
- Edit and Continue
- ClickOnce
- Smart Tags
- Code Snippets
- Exporting IDE Settings
- Line Revision Marks
- Temporary Projects
- Data Inspection Improvements
- Docking Window Changes
So, without further ado let's get started understanding and using these features.
Refactoring
The key tenet of Extreme Programming is constant refactoring. Under this programming model, you are developing code rapidly and iteratively, but to keep your code from becoming a jumbled mess, you must constantly refactor. In other words, making changes to your code like, "pulling a large stretch of inline code into its own method" or "converting a field to be a property." The refactoring support makes this easy to do, as shown in Figure 1.
Figure 1. Example of refactoring in previous versions of Visual Studio .NET
You can access refactoring from the top-level menus, or through a context menu by right-clicking your code. Through refactoring, you can easily turn a field into a property, so the above code becomes:
private String userName;
public String UserName
{
get
{
return userName;
}
set
{
userName = value;
}
}
You can also highlight a section of code and factor it out into its own method, leaving just a method call placed at its original location. However, probably the most timesaving use of refactoring is renaming, which is especially useful for renaming controls. When renaming, the refactoring system is rather intelligent, but if it also provides the ability to preview the changes, as shown in Figure 2.
Figure 2. Preview Changes dialog box
In the PDC bits, refactoring is a C# only feature. However, it has been stated that Visual Basic® will also have some form of refactoring.
Edit and Continue
Visual Basic has always been about rapid application development (RAD). One key feature is the ability to fix runtime errors on the fly. With Visual Basic .NET 1.0 and Visual Basic .NET 1.1, this powerful feature wasn't included. You'll be happy to learn that this feature is on-board for Whidbey. If you run into an exception at runtime, you get an exception helper that provides tips for fixing common errors, but more importantly, you can edit the code, select F5, and it continues right where you left off.
Also, as with Visual Basic 6.0, you can change the instruction pointer so that you control where the application resumes when you continue. The only time this doesn't work is when you make a rude edit, which essentially means that the changes you've made can't be incorporated while the application is running (Visual Basic 6.0 also could not continue after a rude edit, so this is nothing new).
It's also worth noting that C# does not support Edit and Continue. This is currently a Visual Basic .NET only feature, and I know of no statement that C# will support this in the Whidbey release.
ClickOnce
If you've ever worked with href-exes in the .NET Framework 1.0 and .NET Framework 1.1, you've probably realized how many deployment issues href-exes solve. Href-exes are also known as no-touch deployment, or zero impact deployment. Essentially, with versions 1.0/1.1, , you can deploy an application to a Web server, allowing users to browse to the URL for the exe, as in:
<a href="someapp.exe">You can run me by clicking this link</a>
When the user clicks the link, the application downloads to their Internet files cache and runs. To keep this from being a huge security hole, the application permissions are restricted based on the URL (Intranet applications get different permissions than Internet applications, for example), or other factors. This means that some applications no longer need to be deployed in the traditional sense; no more Setup.msi or Windows Installer file.
But for all their glory, href-exes have a number of limitations. First, the .NET Framework must be pre-installed on the client machine. There's no good way to bootstrap the .NET Framework down if it's not there. Also, most non-trivial applications consist of the main .exe and a number of assembly files. With href-exes, the assembly files are downloaded on demand, which is great for corporate Intranet applications, but there's no way to download the application in one shot so that you know it can be safely used off-line. There are other issues as well, such as limited support for versioning, the application doesn't hook into Add/Remove Programs, and the application doesn't install Start menu shortcuts.
The Whidbey release of Visual Studio .NET takes href-exes a big leap forward with the advent of the ClickOnce deployment model. ClickOnce deployment differs from href-exes in some significant ways.
First, ClickOnce applications are self-updating. With href-exe's you can only make the application self-updating through the use of custom code or through the use of a component, such as the .NET Application Updater component. With ClickOnce, updates can also be marked as mandatory or optional. ClickOnce works its magic through two XML manifest files. The first is an application manifest and the second is a deployment manifest. The application manifest describes the application itself, which includes information about the application assemblies, dependencies, and files that make up the application. The application manifest also states the required permissions, and the location where updates can be downloaded. The deployment manifest points to the location of the application manifest and files, and instructs the clients on which version of the application they should be running.
When applications are installed through ClickOnce, they show up in the start menu and they can be uninstalled through the Add/Remove Programs feature. You also control when the application scans for updates. Options include on startup or while the application is running. You also control whether the entire application is downloaded (which is a good choice if it is to be used off-line), or if the application trickles down on demand.
If you want an application to be installable through ClickOnce from Visual Studio, you right-click the project and select Publish Project. You'll first be asked whether you want to deploy the application to an FTP site, an HTTP site, file share, or local path. Next you'll be given the option to specify whether you want the application to be available online and offline or just online, as shown in Figure 3.
Figure 3. ClickOnce Publish Wizard
Once the application is deployed, Internet Explorer opens and lets you test the deployment, as shown in Figure 4.
Figure 4. Internet Explorer test environment
As you can see, the prerequisites link that you provide is a way for a user to download the .NET Framework if they don't already have it installed.
Smart Tags
When you start using Visual Studio .NET Whidbey, you'll find that it's chock full of Smart tags, as shown in Figure 5.
Figure 5. Smart tags in Visual Studio .NET Whidbey
This provides access to information and common tasks without forcing you to constantly navigate away from your work area to some properties window or menu item. Smart tags appear in a variety of places, both in the designers, and in the code editor.
Code Snippets
There are few things that are more useful than a good example. For this reason, when version 1.0 of the .NET Framework was first released, many developers quickly fell in love with the quickstarts that shipped with the Framework SDK. They were full of straightforward code samples that got developers up to speed very quickly on .NET.
In addition to the quickstarts, the help documentation contained code samples for many of the classes and methods. However, the code samples tended to be special purpose, showing the code as used for a specific task. With code snippets, you can insert generic "template" code that requires only that you fill in the blanks. You can access code snippets by right-clicking in the code editor and navigating in the context menu to Insert Snippets, as shown in Figure 6.
Figure 6. Inserting a code snippet
There are snippets of code for accessing the registry, manipulating strings, working with text files and so on.
What if you want to share snippets or create snippets of your own? First, you need to browse to the following location on disk:
c:\Program Files\Microsoft Visual Studio .NET Whidbey\Common7\IDE\Visual Basic Snippets
Inside this folder you'll find a folder structure that is comparable to the one you'll see off the context menu. One thing to be wary of is that only the first level of folders underneath the path above are recognized by the IDE. Next, you need to copy one of the existing files and open it in a text editor. Once the file is opened, you'll notice the file is in an XML format.
To create your new code snippet, all you have to do is modify the relevant sections of the code snippet file. You can even make snippets that allow the user of the snippet to simply tab between the sections of the snippet that need developer-added code. To do this, you leverage the <declarations> element in the code snippet in the same way that the shipping code snippets do.
Note This feature is currently available only in Visual Basic .NET projects.
Exporting IDE Settings
How many times have you reloaded your laptop and had to reset all of those development settings that you've carefully set over the last few months? With Whidbey, migrating and persisting those settings are a simple process of navigating to Tools | Import/Export Settings. You then open a wizard that gives you three choices. The first of these is to export your current settings, the second is to import a set of settings, and the third is to reset the IDE back to default settings.
There's one other reason for going here that's less than obvious. When you install Visual Studio .NET Whidbey, you are asked whether you're a Visual Basic, C#, C++ developer (essentially, what's your sign?) This configures defaults for the IDE, such as F8 for stepping through code if you choose Visual Basic, or F10 if C#. However, you may want to change this after the fact. Search as you might, you won't find a check box to easily toggle between these setting. Instead, you Import the settings for the desired language as shown in Figure 7.
Figure 7. Importing settings for a desired language
Line Revision Marks
Line Revision marks allow you to see the changes you've made during a coding session. When writing code in the IDE, you'll notice yellow and green lines appearing down the left hand side of the code editor window. The green highlight means that code adjacent to that color has been edited prior to the last Save operation. Code that is adjacent to a yellow highlight has been added since the last Save operation. Using this feature allows you to determine the state of code in a given file in your project.
Now what if you don't like green and yellow? All you need to do is navigate to Tools | Options in the IDE, and then choose Show All Settings. After that expand Environment and click on the Fonts and Colors item underneath the Environment folder. Lastly, scroll down the Display Items box until you find the Track Changes after Save and Track changes before Save items. You can change the color at this point for each one.
Temporary Projects
How many times have you found out that you have WindowsApplication53 already on your hard drive? "Really?", you say to yourself, "How did that happen?" Well, as many developers know Visual Studio .NET 2002 and Visual Studio .NET 2003 both had a propensity to persist your temporary ideas as permanent projects on your hard disk. This created the WindowsApplication53 problem.
With this release of Visual Studio .NET though, you should have no more worries about this problem as Visual Studio .NET supports the idea of temporary projects. Visual Studio .NET Whidbey does not save your project until you click on or select Save. Also, if you attempt to close the IDE without saving, it will prompt you to either save or discard the project.
The extremely curious may wonder where these projects are stored while they are considered temporary. Look yonder:
C:\Documents and Settings\[Your Profile Name]\Local Settings\Application Data\Zero Impact Projects
You'll be able to use temporary projects in both C# and Visual Basic .NET projects.
Data Inspection Improvements
When debugging with previous releases of Visual Studio .NET, it was sometimes difficult to view the payload of a variable, property, or object in the IDE if that payload was large in size or contained, for example, XML. With the Whidbey release of Visual Studio .NET you can easily view the data contained in a variable by using the built-in visualizers. When clicking on a variable in the Locals window, you have the ability to choose between one of three default viewers. You can either view the contents of the variable as text, html, or xml in a separate viewer window. This makes it much easier to look at the value assigned to variables when data is html, xml, or when the value is a long string.
Docking Window Changes
If you've used the previous versions of Visual Studio .NET, you've probably found yourself occasionally frustrated when trying to place your IDE windows in the appropriate location. With the Whidbey release of Visual Studio .NET, you can now see exactly where the window will be docked through the use of guide diamonds.
As you move an undocked window around the IDE, you'll notice that more than a few diamonds appear. The four arrows of the diamond reference the sides of the window. As you drag the window, arrows appear and indicate to which side of the IDE the window can fastened .
Figure 8. Docking window
As you can see, you can easily dock to any side of the frame, or if you want to add the window to a tab group, you drop it in the center of the guide diamond.
What About Web Development?
As you begin to work with Whidbey release of Visual Studio .NET, one of the first things you might wonder is where have the Web projects gone? If you go to the standard File | New Project menu you won't see Web projects listed as one of the standard projects types. That's because now you create Web projects from a different set of tools within the IDE. To get to these tools, you navigate to File | New Web Site. Covering these tools in-depth is not a goal of this article. To learn more about Web development, you can use the relevant topics in the MSDN help that ships with the Whidbey release or look at some of the other articles that are focused on Web development with Whidbey on MSDN.
Other Features
- Exception helper: an exception handler bubble appears when an exception is generated in your code. The exception handler bubble gives standard information about the exception, and then gives helpful information on how to prevent the exception from occurring again.
Figure 9. Exception handler bubble
- Auto-Save and Restore: With the Whidbey release of Visual Studio .NET, you can have your projects automatically saved as you work on them. If Visual Studio freezes or is aborted, you can recover your work.
- Build process integration: MSBuild is the new XML-based command line build tool (similar to "make" from the UNIX world). MSBuild is also the tool that is used by Visual Studio .NET to build projects. According to Alex Kipman from Microsoft "In the next 18 months we are exploring the possibility / feasibility of building all of Windows, Visual Studio as well as .NET FX with MSBuild. That project is still in its infancy, but we have it as a team goal that MSBuild needs to be flexible and scalable enough to support products like Windows, Visual Studio or .NET FX."
- Solution Explorer not needed for stand-alone projects: When working with projects in Visual Studio .NET Whidbey, the Solution Explorer does not appear unless you are working with multiple projects that are part of the same solution.
- Task list changes: The task list has numerous additional features in the Visual Studio .NET Whidbey release. Multiple lines of text can now be displayed in any row, columns can be easily sorted by clicking the column name, and you can move columns using drag and drop.
- "Just my code" debugging: With Visual Studio .NET Whidbey, you'll be able to simply step through the code you've written and skip over designer-generated code. The big benefit of just my code debugging is that you only have to focus on the code that you wrote. You can turn this feature on and off by navigating to Tools | Options in the IDE.
Summary
Based on these features, you can see that Visual Studio .NET Whidbey is an incremental, but significant release, geared strongly towards developer productivity. Visual Studio .NET 2003 represented a good tune-up to the IDE. Visual Studio .NET Whidbey adds power steering, AC, and cruise control to your IDE ride.
Sean Campbell and Scott Swigart are Sr. Principals of 3 Leaf. At 3 Leaf, Sean and Scott spend their time analyzing how emerging technologies can be used when building solutions. With this knowledge, 3 Leaf helps companies successfully integrate new technologies into their business, through a variety of consulting, mentoring, and training services. For the companies that are inventing emerging technologies, 3 Leaf builds highly technical content that user of that technology can utilize when doing real implementations. You can contact Sean and Scott at sean@3leaf.com, scott@3leaf.com, or through the 3 Leaf Web site at www.3leaf.com.
