The Platform Target is an often overlooked option in the build configuration for Visual Studio 2005 and 2008 projects.  For C# projects, you will find this option on the Project Properties dialog under the build tab.  For VB.net projects, the setting is found on the Advanced Compiler Settings dialog which is made available via the Advanced Compile Options button on the Compile tab of the Project Properties.  The list of available options are:

1. Any CPU
2. x86
3. x64
4. Itanium

The meaning of these options is often misunderstood.  Based on their names, one might think that the compiler will generate code differently based upon the setting.  However, the C# and VB.net compilers only generate IL code that is taken to native code by the CLR at runtime using the just-in-time compiler (unless ngen is used but that is another discussion).  The fact is that this setting actually does not affect the build of the assembly in any way except to set the platform status information on the assembly’s CLR header.  In other words, the Platform Target setting is meant to communicate the platform that the developer intends to be compatible with.

The default setting, Any CPU, means that the assembly will run natively on the CPU is it currently running on.  Meaning, it will run as 64-bit on a 64-bit machine and 32-bit on a 32-bit machine.  If the assembly is called from a 64-bit application, it will perform as a 64-bit assembly and so on.

If the project is set to x86, this means the project is intended to run only as a 32-bit process.  A 64-bit process will be unable to call into an assembly set as X86.  Reasons to set your project as x86 include dependencies upon native DLLs that are only available in 32-bit or making native calls assuming 32-bit .  Applications and assemblies marked for x86 can still run on 64-bit Windows.  However they run under WOW64.  Visual Studio itself runs under this emulation mode since it is a 32-bit application.

Setting the project to x64 will specify that the assembly must run under 64-bit Windows.  Attempting to run the assembly on 32-bit Windows or call the assembly from a 32-bit process will result in a runtime error.

The final, and likely least common, setting is Itanium.  This setting specifies that the assembly will only run on an Itanium processor.  The only reason to set your project for Itanium is if it has dependencies on native DLLs compiled specifically for the Itanium processor.

Developers should be aware that simply marking Platform Target of an assembly as Any CPU does not guarantee that it will run on both 32-bit and 64-bit Windows.  In fact, since Any CPU is the default setting, there are likely many applications that actually depend upon 32-bit processing but are not marked as such.  These assemblies will fail under 64-bit Windows when run from a 64-bit process so it is important to perform testing for your applications before users are migrated to 64-bit.  The somewhat increasing popularity of Vista x64 will soon elevate the importance of this type of testing.

Another point to be aware of when attempting to migrate to 64-bit processing for .Net applications is the dependency upon assemblies originally built using Visual Studio 2002 and 2003.  All assemblies targeting .Net 1.0 and 1.1 will be 32-bit only (x86) so these assemblies will need to be upgraded to newer versions, if available, or the functionality will need to be replaced in order for the process to execute as 64-bit.

Here are some excellent links on MSDN that should be required reading before migrating a complex project to 64-bit Windows:

Visual Studio 64-bit Applications

Migrating 32-bit Managed Code to 64-bit

I’m a keyboard junkie, perhaps a remnant left over from using Vim and Emacs-variants in my early days of programming. I dislike having to move over to the trackball to accomplish something, simply because it breaks my train of thought and always seems to take too long to get the cursor positioned where I want it, then use guestures/motions to get a task accomplished.

Keyboard shortcuts are a great productivity boost to me, and thankfully Visual Studio has a plethora of them available. Furthermore, you can assign shortcuts to just about any command you could possibly think of.

Here are some of my favorite keyboard actions, broken into various sections.

NAVIGATION

Cycling through cursor positions is a great way to save time moving between areas you?re working on. Note that this will actually move you between files you?ve been working in, too.

This is handy way to jump between the opening and closing marks of a region, quote, or brace set. It?s also a handy way to check if you?ve got your braces properly matched. Another way of doing that would be to format the entire file with Ctrl-A, Ctrl-K, Ctrl-F, but that?s more keystrokes.

BOOKMARKS (Note these are chord key combinations)

Bookmarks work much like the cursor marks discussed above, but you?re able to control exactly where you want to bounce back and forth between.

FAVORITE NAV TRICK FROM VIM DAYS

I use this all the time in Vim since it’s a quick way to jump to a spot where you know the line number, even if it’s just a few lines up on the screen.  Hit Ctrl-G, type in a line number and press Enter instead of reaching for the mouse, or hitting the up arrow a bunch of times.  I use it even when I’m not certain of the exact line number, but know the general region I want to hit.

OUTLINING

I think the Stop Outline Mode is pretty useless, but I love the other commands. I like clearing off extra cruft from the screen, allowing me to focus on what I?m working in at the moment.

CLIPBOARD RING

The clipboard ring’s a terrific tool for doing mass edits.  Move a number of items into the clipboard ring via any Copy or Cut command, then cycle through those items as you’re pasting away.

OTHER GOOD ARTICLES

Ari Bixhorn’s MSDN TV episode on his top ten Code Editor Tips and Tricks.

SathishVJ’s article on The Code Project.

Visual Studio’s a great development environment, but out of the box it’s not the greatest thing for displaying code to an audience via an overhead projector. It doesn’t matter if you’re giving a presentation to a thousand geeks at a conference or walking through a code review with two other members of your development team — your work isn’t effective if your audience can’t see what you’re talking about.

Visual Studio 2005 offers several great tricks for making presentations more effective. You can change font sizes, rearrange your windows, and toggle toolbars off and on to maximize screen real estate. VS2005 also gives you the ability to easily export and import settings so that you can configure your regular work environment and quickly change to an environment more suitable for presentations. You can also speed up your presentation by taking advantage of the General Toolbox’s ability to store code snippets for quick retrieval. Additionally, several macros and a free tool can make your presentation life much easier when adjusting font sizes or trying to display an obscure part of the screen.

Be sure to save your current IDE settings before tweaking things up for presentations. Saving your settings will allow you to quickly switch between your regular development profile and the settings you’ll configure for presentations.

Many active presenters favor Lucida Console at 14 points for presentations. Lucida Console has been acknowledged as a great font for audience viewing. The new font Consolas from Microsoft’s Longhorn operating system is a mono-spaced typeface with terrific readability. Unfortunately, this font is only available in Windows Vista and it’s against Vista’s End User License Agreement to copy it to a “downlevel platform” as the folks at Microsoft say. However, Microsoft plans release this font as a separate download for Visual Studio 2005 sometime after VS’s release, so you’ll be able to get Consolas regardless of your platform.

Set your font selections through the Tools -> Options -> Environment -> Fonts & Colors dialog. This dialog allows you to configure fonts for individual windows, or by groups of windows. For example, you could configure only the Watch window, or you could configure all Watch, Locals and Autos Tool windows at once.

Sometimes all the preparation in the world doesn’t quite pan out. Maybe Lucida Console 14 isn’t reading well and you need change the size a notch or two in either direction. Rather than forcing your audience to suffer through you pulling down menus and clicking through dialog boxes, take advantage of macros bundled with VS 2005. Sara Ford, previously a Software Design Tester extraordinaire, created two very useful macros to change font sizes with great ease.

Macros.Samples.Accessability.DecreaseTextEditorFontSize and Macros.Samples.Accessability.IncreaseTextEditorFontSize let you decrease and increase font sizes easily. This is especially easy if you’ve bound them to a keyboard shortcut. Select Tools -> Options from Visual Studio’s main menu, then select the Keyboard item under the Environment section. Click in the “Show Comamnds Containing” box and enter “fontsize”. The list of commands will filter down, leaving Ford’s macros right at the top. Set the “Use new shortcut in” to “Text Editor”, then select a keystroke to bind them to. I’ve set mine to Ctrl-Shift-Alt-UpArrow and Ctrl-Shift-Alt-DownArrow since those two aren’t already in use and they’re not completely convoluted, messy chords — and they won’t get used all that often.

Font readability is also impacted by Microsoft’s ClearType feature, available only in Windows XP. ClearType smoothes out fonts, making them appear less pixilated and more like printed characters. Microsoft’s literature on ClearType says it’s targeted to LCD displays, but your system may benefit from activating it regardless of the display type you have. (Microsoft leaves this option off during installation, another less-than-helpful default setting.)

Turn on ClearType by right-clicking anywhere on the Desktop, then selecting Properties. Select the “Appearance” tab, then click the “Effects” button. Ensure the checkbox “Use the following method to smooth edges of screen fonts” is checked. Pull down the list box and select the “ClearType” option. Close out the dialogs and you’ll notice a tremendous difference if you’re using an LCD screen, and you may notice a significant difference if you’re on a CRT.

Now that you’ve got your fonts configured as you prefer for presentations, save off your settings by again. Now you’ve got both profiles ready for easy use.

Maximizing real estate during a presentation is an important trick too. Make use of the full- screen mode by pressing Shift+Alt+Enter. This hides any open toolboxes, tool windows, and all toolbars, leaving you with just scrollbars at the sides and a menu bar at the top.

One handy use of this is to lock open your Solution Explorer, Server Explorer, or other tool window you’re needing to use. Now you can quickly toggle back and forth between your code and tool windows for opening new examples, navigating a database, etc.

How many presentations have you had to sit through while the presenter spent too much time typing code on a keyboard, correcting various typing mistakes? Typing in code is not the best use of your or your audience’s time unless you’re demonstrating Intellisense or some other keystroke-related feature.

Visual Studio 2005 gives you the ability to put code snippets on the toolbox, enabling you to skip manual entry of code. Moving snippets to the toolbox will save you great amounts of time and keep your presentation flowing well. Simply highlight a section of code you’ll be needing to add during your presentation and drag it over to the general toolbox.

You can also make effective use of Magnifixer, a freeware screen magnifying tool, to ensure your audience can read what you’re displaying in the IDE. Grab Magnifixer and install it.

Magnifixer comes in very handy when you’re trying to clearly display a portion of the IDE which won’t allow you to set font sizes, such as the Solution Explorer, menus, etc. Simply bring Magnifixer to the front, resize it as needed, then drive your cursor over the portion of the screen you want to display. You can also magnify menus and context menus by selecting the “Stay on top” option on Magnifixer’s lower status bar.

Gadgets and hacks alone won’t get you through a presentation. You’ll need to practice, practice, and more practice to ensure you’ve got both the content and the tools down pat. Scott Hanselman, chief architect of Corrillian and a well-known speaker, has some great presentation tips. Drew Robbins, Microsoft’s Great Lakes Regional Developer Evangelist, also has some great tips on his blog. Tom Peters, not a software guy but a world-renowned speaker on many topics, has great advice at his website.

While the Visual Studio build process is familiar for all .NET developers, not everyone realizes the build customization capabilities that can be accomplished with just a little work. You can easily put together tasks that occur before, after, and even during a build.

NOTE: With the release of Visual Studio 2005, a new build tool—called MSBuild—is used within the Visual Studio environment. This tool provides many build process tasks and is similar to NAnt in capability. For pre- and post build operations for automated builds I would suggest looking at MSBuild tasks rather than the project level pre- and post-build commands.

Pre- and Post-Build Event Commands

In nonweb projects, you can create pre- and post-build event commands. As their names suggest, these are commands that you can customize to run just prior to or after a build. You can even control whether the post-build event executes at all depending on the outcome of the build. In the previous version of Visual Studio these commands could only be found in C# projects, but Visual Studio 2005 now exposes them for VB.Net as well. For C# projects you can find the settings on their own tab in the Project Properties pages, while for Visual Basic projects they are found via a Build Events button on the Compile tab in the My Project properties window.

Project build events for C# projects

Project build events for VB.Net projects Note the build Events button in the bottom right corner of the window.

Just type in the command you want to occur for each event type. You can click on an Edit Event button under each event type to help “build” up your command using a set of tokens or “Macros”. These variables help provide some shortcuts to including pathnames, project output locations, and other information into your event commands. Note that the variables are sensitive to the type of build you are compiling, so if you switch to a release build, the variables referencing the output directory will be correctly pointed at the \bin\release directory (or wherever you have set up the output directory to be).

Macro examples

The build event command lines are simply command-line operations that will be executed at the specified time. The commands are saved in the project file and are Targets configured in MSBuild to be used by the build process to execute the commands. Note that Visual Studio 2005 does not copy these commands out into batch files during a build like its predecessor did.

Note that a failing build event will be shown in the build output and listed in the Build Error task list along with any other build errors. A failing pre-build event will cause the build to stop, while a failing post-build event will still mark the build as a failure even if the build of the code succeeded without errors. You can choose to have the post-build event occur every build, only if the build succeeded, or when the project output (the resulting .dll or .exe) actually changes.

A great example of using a custom post-build event is when you have multiple configuration files. Whe n you add an app.config file to your project, it will automatically be copied to the output directory of the project and renamed to match up with the project output file (e.g., CSharpWinFormApp.exe.config), but the IDE will not do the same with other custom configuration files. What if your project had multiple .config files to break up the settings? For example, you have app.config to store application configuration but then you also have an EndUser.config file to store user-specific settings that you didn’t want to mix with the application settings. By default, this configuration file would not be copied to your output directory, and the application would receive an exception if it went looking for the file during execution. To get around this, a custom post-build event can copy the EndUser.config file to the output directory every time a build succeeds.

In the Build Events, choose to run a Post-Build event when a successful build occurs and add a Post-Build event command line of:

copy "$(ProjectDir)EndUser.config" "$(TargetDir)"

Note the use of quotes around the variables and commands—the quotes are there because there may be spaces in the file and pathnames. Also, the variables that generate pathnames will append an ending slash automatically. After a successful build of this project the current version of the EndUser.config file in the project directory will be copied to the output directory.

Copying files after a build is just one example of how these build events can be useful. More complex operations can be performed as well. For example, a Windows script or executable could be run when a build completes to kick off a set of test scripts against the newly built output. For automated builds in Visual Studio 2005 these types of operations would be configured as MSBuild Tasks, but within the IDE the pre- and post-build commands can make a life a lot easier.

Handling Build Events

Some of the limitations of the custom pre- and post-build command events are that they are available for only nonweb projects and are only project specific. They don’t give you the flexibility to deal with building a multiproject solution or provide a way of handling more complex build outcomes other than a successful build, a failed build, or a changed project output. For more advanced handling of build events, we can turn to the Visual Studio Macro Environment. By using the IDE build events we can configure some operations to occur before, during or after a build no matter what project we are building or what type of project it is.

To hook into the IDE build events, all we need to do is create some simple macros. Open up your Macro IDE (from Tools ? Macros ? Macro IDE or Alt-F11). If you haven’t used the Macro IDE before, the first thing you’ll notice is that it resembles the regular VS.NET IDE, except the Macro IDE is used solely for the creation, editing, and compiling of macros that can be used within your Visual Studio IDE.

Open up the MyMacros project and see if it already contains an EnvironmentEvents module. If it doesn’t, go ahead and copy the one from the Samples directory into your MyMacros project. The code looks like this:

Option Strict Off
Option Explicit Off
Imports EnvDTE
Imports EnvDTE80
Imports System.Diagnostics
Public Module EnvironmentEvents
#Region "Automatically generated code, do not modify"
'Automatically generated code, do not modify
'Event Sources Begin
<system.contextstaticattribute()>Public WithEvents
	DTEEvents As EnvDTE.DTEEvents
<system.contextstaticattribute()>Public WithEvents
	DocumentEvents As EnvDTE.DocumentEvents
<system.contextstaticattribute()>Public WithEvents
	WindowEvents As EnvDTE.WindowEvents
<system.contextstaticattribute()>Public WithEvents
	TaskListEvents As EnvDTE.TaskListEvents
<system.contextstaticattribute()>Public WithEvents
	FindEvents As EnvDTE.FindEvents
<system.contextstaticattribute()>Public WithEvents
	OutputWindowEvents As EnvDTE.OutputWindowEvents
<system.contextstaticattribute()>Public WithEvents
	SelectionEvents As EnvDTE.SelectionEvents
<system.contextstaticattribute()>Public WithEvents
	BuildEvents As EnvDTE.BuildEvents
<system.contextstaticattribute()>Public WithEvents
	SolutionEvents As EnvDTE.SolutionEvents
<system.contextstaticattribute()>Public WithEvents
	SolutionItemsEvents As EnvDTE.ProjectItemsEvents
<system.contextstaticattribute()>Public WithEvents
	MiscFilesEvents As EnvDTE.ProjectItemsEvents
<system.contextstaticattribute()>Public WithEvents
	DebuggerEvents As EnvDTE.DebuggerEvents
<system.contextstaticattribute()>Public WithEvents
	ProjectsEvents As EnvDTE.ProjectsEvents
<system.contextstaticattribute()>Public WithEvents
	TextDocumentKeyPressEvents As EnvDTE80.TextDocumentKeyPressEvents
<system.contextstaticattribute()>Public WithEvents
	CodeModelEvents As EnvDTE80.CodeModelEvents
<system.contextstaticattribute()>Public WithEvents
	DebuggerProcessEvents As EnvDTE80.DebuggerProcessEvents
<system.contextstaticattribute()>Public WithEvents
	DebuggerExpressionEvaluationEvents
	As EnvDTE80.DebuggerExpressionEvaluationEvents
'Event Sources End
'End of automatically generated code
#End Region
End Module

This sets up the types of IDE events you can hook into. Now if you open the EnvironmentEvents module in your MyMacros folder, you can select the BuildEvents from the Class Name drop-down (the left drop-down box above the code). Then from the right Method Name drop-down, you can select one of four build events to hook into:

NOTE: These events fire even if build errors or warnings occur, and the default behavior of Visual Studio is to build all projects in a solution even if projects earlier in the build have failed.

For an example, you can add the capability to stop the build process when a project fails and display a message box in the IDE to note when the build process is complete (in case someone isn’t paying attention to the Build output).

Canceling a failed build

The normal behavior of Visual Studio is to build every project in a solution, even if one or more of those projects fails. If you have a half-dozen projects in your solution, then this can sometimes take a little while. It is much faster if the build quits when any of the projects fails. By handling a build event, you can ensure that.

Start by selecting the OnBuildProjConfigDone event from the Method Name drop-down above the code. The Macro IDE will automatically generate the method signature to hook the event:

Private Sub BuildEvents_OnBuildProjConfigDone( _
ByVal Project As String, _
ByVal ProjectConfig As String, _
ByVal Platform As String, ByVal SolutionConfig As String, _
ByVal Success As Boolean) _
Handles BuildEvents.OnBuildProjConfigDone
End Sub

Since this event will fire whenev er a project completes a build, you can easily stop the rest of the build from occurring by using the ExecuteCommand method of the DTE object to send a Build.Cancel command to the IDE. The DTE object is a reference to the Visual Studio IDE, and using DTE.ExecuteCommand method to cancel the build is the same as hitting Ctrl-Break during a build or typing Build.Cancel into the IDE command window. Using the Success parameter of the event signature, you can determine whether you want to stop the build. The code looks like this:

Private Sub BuildEvents_OnBuildProjConfigDone( _
ByVal Project As String, ByVal ProjectConfig As String, _
ByVal Platform As String, ByVal SolutionConfig As String, _
ByVal Success As Boolean) _
Handles BuildEvents.OnBuildProjConfigDone
If Success = False Then
'The build failed...cancel any further builds.
DTE.ExecuteCommand("Build.Cancel")
End If
End Sub

Alert the user on a successful build

Now, the idea was to capture the end of the build process to alert the user that the build was complete. For that you hook into the OnBuildDone event the same way you did for the project build complete. This time, you’ll use a standard Windows message box to display an informative alert:

Private Sub BuildEvents_OnBuildDone( _
ByVal Scope As EnvDTE.vsBuildScope, _
ByVal Action As EnvDTE.vsBuildAction) _
Handles BuildEvents.OnBuildDone
'Alert that we finished building!
System.Windows.Forms.MessageBox.Show("Build is complete!")
End Sub

These are some pretty simple examples, but you have the power of the .NET Framework in your hands for any of these events so you are limited only by what you can come up with to handle. You can share these with other developers by just sending them the code to include in their own macro project or take it a step further and create a Visual Studio add-in that hooks these events and distribute it that way. If you take a look at the other IDE events you can tap into, you will understand why the Visual Studio IDE is so extensible.

Something to consider when you are implementing custom build events is that they are handled within the IDE only. Build events implemented using the extensibility of the IDE (macros or add-ins) will not fire if the build is run from the command line and they are executed for all project built with the IDE. However, pre- and post-build event commands will execute only for the project they are added to and even if the build is being run via the command line with devenv.exe /build or with MSBuild. This could be important if you want to automate your build process on a build machine.

In my previous column Optimize Visual Studio for Presentations, I mentioned altering font size in text editor windows to improve readability for presentations.

Readable text in the editor window is critical to a good presentation, but just as critical is the ability to read other portions of the Visual Studio IDE.  Ever tried to understand a project layout on the screen when you can’t read a #(*%$!! thing in the Project Explorer?  Ever been frustrated because you can’t see what a speaker is pointing at in the Server Explorer?

Visual Studio 2003 offers a command line option to set font sizes throughout Visual Studio, even in dockable windows like Server and Project Explorers.  Simply start VS via the command line and pass it the /fs switch, specifying a font size in points.  Visual Studio will start with your set font size and remain that way until you reset it with another /fs switch.

Visual Studio 2005 doesn’t have this handy command-line switch, but you can achieve the same results by altering the font size in your operating system.  In Windows XP/2000 you do this on a profile-by-profile basis.  Scott Hanselman’s presentation tricks blog post makes a great suggestion: create a separate logon profile with Administrator rights just for demos.  Set that profile’s font size to a large one and you’ll have a readily-configured system just for presentations.

In Windows XP, you can set the profile’s font sizes by right-clicking on the desktop, then selecting Properties.  On the Appearance tab, pull down the Font Size list and select Large or Extra Large.  Note that this will not affect Visual Studio 2003’s fonts, only 2005.

Font sizes in Visual Studio’s text editor window won’t change, but all the other “unsettable” features will.  You’ll end up with a shiny, readable IDE and make your audience much happier.

Don’t forget about the command prompt, either.  Access its Properties list by clicking the application icon in the window’s upper left corner, or by hitting Ctrl-Space.  Set your font sizes on the Fonts tab.  Lucida Console 14 point is a good choice.  Also, try out the hideous bright green text on a black background.  It sounds awful, but is probably the most readable combinations.

Leaders in our software development industry are incredibly productive for a number of reasons, one of which is their intimate familiarity with the ins and outs of the tools they use. This article is the first in the “Ask The Pros” series which explores how some of those leaders get the most out of their tools.

Visual Studio is a powerful coding environment, but it can’t do everything. Smart folks around the .NET development world have created scads of addins for Visual Studio. Addins range from larger commercial packages to tightly focused freeware widgets. Commercial addins include tools such as JetBrain’s ReSharper, Developer Express’s Code Rush for productivity enhancements, and Rational Software’s XDE Developer for Visual Studio which provides a wealth of design and implementation features. Freeware, public domain, and open source addins provide everything from simple hungry whitespace deletion during editing to code complexity metrics, with documentation and testing in between.

In this article several highly accomplished developers, architects, and program managers discuss their favorite addins for Visual Studio .NET. Respondents for this article are:

• James Avery, Principal of InfoZerk, Inc., author of Visual Studio Hacks, and host of this website.
• Ben Carey, Senior Consultant at Statera Consulting in Denver Colorado
• Dave Donaldson, President/CEO of Arcware, Inc. and creator of CodeKeep
• Scott Hanselman, Chief Architect at Corillian Corporation, a leading provider of eFinance solutions
• Josh Ledgard, Microsoft’s Lead Program Manager for Visual Studio Aftermarket Community solutions team
• Alex Lowe, Program Manager at Telligent Systems
• Roy Osherove, Principal of Team Agile located in Israel, and a consultant for Agile software development and .NET Specialist

Ben Carey

Ben Carey’s favorite addin is JetBrain’s ReSharper. Says Carey, “I can’t imagine writing code without ReSharper. The named-refactoring support, live templates, visual indicators, and code acceleration capabilities make me feel at home in Visual Studio. ReSharper helps me stay test-driven and speeds up my development by automating frequent and repetitive actions. Overall, the tool does a tremendous job of aiding in the flow of day-to-day and minute-by-minute coding.”

Coding is a highly creative process. Great developers seem to hit a creative zone or flow where things are really clicking and some hidden corner of the brain takes over the entire process. Good tools help by enabling the developer to keep focused on the creative task at hand rather than mundane tasks like stubbing in methods or reordering method parameters. Carey’s emphatic about ReSharper’s capabilities helping him stay in the zone: “I love being able to write a test for a method that I haven’t implemented yet, and then right click the class name and generate the stub. It doesn’t matter how many times I use the capabilities of ReSharper, it still brings a smile to my face every time I use the tool. I keep a printout of the shortcut keys for ReSharper beside me to constantly remind me of all the great features that are available.”

Two other favorite addins of Carey’s: TestDriven.NET for its feedback inside VS.NET, and GhostDoc for its ability to create consistent code comment structures.

Roy Osherove

Osherove’s favorite addin is the same as Carey’s. ReSharper has “saved me so much time and effort it’s not even funny. I hope their version for 2005 will be just as good. Personally I find myself more productive with VS 2003 + Resharper than VS 2005 without. Its navigation abilities are to die for and VS has a long way to go before it can compete with them, including the amount of possible refactorings.”

Osherove finds ReSharper’s refactoring support a huge advantage. “You can of course do the basics like extract method, but you can also reorder parameters (difficult without it), convert text to a local or field variable, convert var to field and vice versa, convert to constant, extract interface, extract base class and many more.”

Scott Hanselman

Hanselman is a huge fan of another productivity tool: Developer Express’s CodeRush. He’s ardent about the time CodeRush saves him. “I use it to type 50% less in VS.NET. CodeRush lets me type less and do more. It’s more than just a macro or template expansion tool, it’s almost a reimagining of how to write code. Code, by its nature, is very verbose. Why write ‘string’ when the ‘trin’ middle part isn’t adding value but still wastes keystrokes? I type ‘sg’ and get ‘string.’ I type ‘pdt’ and get a complete property definition typed as a DateType including a private field. This is just one simple example of hundreds of included templates.”

Another benefit of CodeRush is its extensibility features. Code templates can be quickly added in for quicker generation. Better yet, CodeRush provides developers a simple, quick API to use for generating their own plugins. Wizards help speed the process. Says Hanselman, “I also like that CodeRush includes its own Managed “DOM” over the Visual Studio COM-based craptastic Add-in model. Writing a CodeRush Add-in is event-based and fantastically easy. Have you ever written a standard Add-in for VS.NET? Let’s just say it’s highly non-trivial. While CodeRush does cost money, a lot of folks don’t realize that DxCore, the underlying engine that supports CodeRush Add-ins is free. My favorite CodeRush Add-in is CR_Documentor by Travis Illig, an extension/repurposing of Lutz Roeder’s Documentor tool as a VS.NET toolbox that tracks your C# XML Comments and renders them as they would appear as MSDN help.”

[Note: Developers interested in the DxCore engine should realize that it's freely available only for personal use.]

Hanselman’s well-known in the development industry for his fanatical hunger in searching out new tools. See his list of Ultimate Visual Studio Addins, and also his wider-ranging list of Ultimate Tools.

Dave Donaldson

Dave Donaldson joins Carey in the group of TestDriven .NET fans. Like Carey, Donaldson likes TestDriven’s integration inside VS’s IDE. He also appreciates TestDriven’s debugger integration: “Another great thing about TestDriven.NET is its ‘Test with Debugger’ functionality. The ability to set a breakpoint in code, then right-click on your project and select ‘Test with Debugger’ is a huge timesaver.”

Donaldson’s the creator of another VS.NET addin: CodeKeep. “CodeKeep is nice because it allows you to save code snippets to a central repository within the IDE; it can also search for snippets in the central repository.”

Josh Ledgard

Good addins don’t have to be huge toolsets to be highly useful to good developers. Both James Avery, author of Visual Studio Hacks and the host of this site, and Josh Ledgard favor tools which help them get code documentation done more quickly. Ledgard’s choice is VBCommenter, available at GotDotNet.  “VBCommenter was a favorite because of the required commenting documentation we would have to write in our test automation code.”

Ledgard’s also a fan of Gaston Milano’s Whidbey Commands tool because it extends VS.NET 2003 with many of VS.NET 2005’s enhanced commands.

Alex Lowe

Alex Lowe’s favorite addin is Unleash It. Lowe likes Unleash It’s ability to help web developers get simple deployment tasks done in Visual Studio .NET 2003. “Short of a full on deployment project, Visual Studio does not have adequate facilities for publishing only the required files needed to deploy and ASP.NET application. Deployment projects are overkill for lots of the work I do.” Unleash It has a simple set of folder and file filters making it simple to “publish (via FTP or to a local folder) only the files one should publish when preparing to do a production deployment of an ASP.NET application.”

James Avery

Like Carey, Avery is a big fan of GhostDoc, and bemoans its lack of support for VS 2005. Asked what his favorite addin was, he replied, “A couple of months ago I would have said TestDriven.NET, no contest. Now that I am working more with Visual Studio Team System with the built in testing functionality I would have to go with GhostDoc. You never realize how much you miss something until you can’t use it, and of all the add-ins that have not yet been revised for Visual Studio 2005 I miss GhostDoc the most.”

GhostDoc’s simplicity is what Avery loves. “GhostDoc is the kind of add-in I like. It doesn’t try to do everything for you, it doesn’t add any additional files or complexity to your projects, it just does one thing and does it very well. GhostDoc helps make the tedious process of commenting your code with XML comments just a little bit easier.”

Avery closes out this set of tips with a list of his other favorites: The WindowsManager powertoy, SmartPaster, Control Outline Poweroy, Mouse Bindings Powertoy, CodeKeep, Pinvoke.NET, WSCF, and many others. “There are so many great free add-ins available. I am always amazed by how many people don’t take advantage of these free tools.”

Debugging is a skill with several learning plateaus. Anyone can fire up the debugger in Visual Studio, set a few breakpoints, and step through various code modules while using watches. The climb up to next plateau might involve learning how to use other aspects of the debugger such as the immediate window, or better understanding how to dig through various data types to find pertinent information. Higher levels of might involve full understanding of Visual Studio’s debugging capabilities, and how to best make use of the features during a debugging session.

Skilled software development professionals have climbed up these plateaus already, their experience honed in the school of hard knocks, and if they’re lucky, via good mentors. They’ve built up a list of tricks and methods to best use the tools available to them, tune their debugging environment, and quickly locate problems.

In this article several highly accomplished developers discuss their tricks for debugging in for Visual Studio .NET. Respondents for this article are:

• James Avery, Principal of Infozerk, Inc., author of Visual Studio Hacks, and host of this website.
• Ben Carey, Senior Consultant at Statera Consulting in Denver Colorado
• Kate Gregory, founding partner of Gregory Consulting Limited
• Scott Hanselman, Chief Architect at Corillian Corporation, a leading provider of eFinance solutions
• Josh Holmes, principal and senior software consultant with SRT Solutions
• Drew Robbins, Developer Evangelist for Microsoft’s Heartland District
• Roy Osherove, Principal of Team Agile located in Israel, and a consultant for Agile software development and .NET Specialist
• Bill Wagner, Founder/Consultant with SRT Solutions and author of “Effective C#”

Kate Gregory

Gregory’s a fan of screen real estate when debugging. “I kill dynamic help and stack my properties window in with everyone else instead of taking up half of one side vertically. Then I unpin pretty much everything…. I love screen real estate.” She also tends to switch profile types and her environment settings often. “I use the ‘Visual Studio Developer’ layout most of the time. I flip to the ‘Visual C++ Developer’ layout if I’m about to do a C++ presentation, for the audience’s sake. I use import/export settings a lot.”

Gregory also gets a lot of use from various windows, saying “I make sure that autos, locals, and call stack are all visible when I’m at a breakpoint, and I LOVE the new Quick Console in 2005. I am also a longtime fan of the immediate window. Partly because, when I’m working in VB, it lets me show off my way-cool-can-you-believe-I-remember-this skills from my BASIC days of almost two decades ago, like ‘?’ for print.”

Practical use of various VS features is high on Gregory’s list of tricks: “Use the data tips. Drill into things and see what all the values are. Set conditional breakpoints. I just cringe when I watch people hit F5 over and over and over so they can get to the time through the loop when i is 15 or whatever. Use the call stack to figure out how you got here in the first place.”

James Avery

Sometimes features go unnoticed, lost in the many other features in Visual Studio. Avery points to the script debugging capability of VS: “With the recent fascination of AJAX and JavaScript one feature often overlooked is the script debugging baked right into Visual Studio. All you need to do is enable it in Internet Explorer and you are ready to start debugging.”

Many, but not all, pros use various tools to help them in debugging. Avery counts two tools as helpful in his work. “I am a big fan of the new Visualizer model in Visual Studio 2005. One of my favorites is the Cache Visualizer from Brett Johnson. It gives you a great view into the ASP.NET cache, what dependencies are there, and more.”

Breakpoints are central to any debugging session, but sometimes they don’t function as you’d expected. Avery’s second helpful tool is ControlAV’s BreakPoint Helper http://www.controlav.com/bphelper/. “It’s great for figuring out why your breakpoints aren’t working.”

Ben Carey

TestDriven.NET http://www.testdriven.net/, a Visual Studio plugin written by Jamie Cansdale, gets lots of attention from Carey, who uses “TestDriven.net as a harness for my debugging. I’ve usually written a test before I write the code so I almost always have a starting point for my debugging. The ‘test with… debugger’ functionality is a great starting point for debugging. When I have my tests defined with deterministic inputs, I always have a way to repeat the situations that I am debugging. The tests that accumulate while debugging provide me with good documentation if I ever need to come back to the code that is in question.”

Scott Hanselman

Hanselman is also a fan of TestDriven.NET. He’s emphatic about writing good tests first, though, saying “Use Test Driven Development along with TestDriven.NET. It may be hard to believe, but the better your tests are the less often you’ll need to use the Interactive Debugger. I debug less when I have good tests.”

Hanselman’s blog reveals his fascination with gadgets. Hanselman carries this over into his debugging work: “I use the Ergodex (http://www.ergodex.com) to create custom debugging keybindings so things like QuickWatch are one keystroke instead of two.” More information on this setup can be found on Hanselman’s blog.

Debugging-specific addins aren’t part of Hanselman’s toolkit, but he does recommend “Zanebug http://www.adapdev.com/zanebug/, a free test runner (think NUnitGui on steroids), when I want to do Testing along with integrated performance counters.”

Josh Holmes

Holmes casts a third vote for TestDriven.NET, noting the ease of writing “a small unit test that will create the scenario that I’m trying to test and then I can debug that by running just that test. These unit tests are also compatible with NUnit so it makes it easy.”

Watches and breakpoints are the workhorses for Holmes. “The watches allow me to quickly see what all of the data is when I enter a particular function. This is an immense help when trying to track down an issue. The breakpoint functionality in VS.NET is fantastic because it allows me to not only set a break every time I hit a line, but to only break there when certain conditions are met. For example, I can hit a break point in a loop every 10th time that it runs through or only break on a certain line if a Boolean variable is true and so on.”

Roy Osherove

“One of the coolest unknown features in VS 2005 is the ability to set ‘Trace Points’,” says Osherove.  “You set them either by right clicking on a breakpoint and selecting ‘When Hit’, or right clicking on the user pane and selecting ‘Add tracepoint’ from one of the submenus.” Osherove finds these very helpful since “they do automatic tracing by method name, module and various other ‘macros’ without breaking when the code is reached. So you get effortless tracing in debug mode.” He hopes they’ll be developed further, maturing “into a more configurable and extensible feature which will allow you to trace even in release mode, at the client’s site, based on configuration.”

Osherove also points out a useful attribute, DebuggerStepThrough, which “allows you to ’skip’ pieces of code you’re not interested in stepping through using the debugger (like get-set properties for example). It makes debugging faster and less annoying.”

Debugging multiple threads can be a difficult task. Osherove offers up a useful tip for this situation: “When debugging multiple threads its good to know that you have the ability to step through a specific thread’s execution path by selecting the thread you want from the ‘threads’ combo. You can add that toolbar to the VS toolbars by rightcliking on the main toolbar.”

Osherove casts yet another vote for TestDriven.NET as an invaluable debugging tool. “Jamie Cansdale rocks.” He also has a terrific trick for use in the Immediate Window: “Add a debug method to your code that does something like iterate through all the objects in a collection. Then you can call that method from the immediate window while in debug mode and it will enumerate various things for you. Think of it like a command-line-debugger-helper. You can write as many of those as you like.”

Drew Robbins

Fancy functionality and tools are great, but sometimes simplicity rules for usefulness. Robbins is a fan of the ease of debugging web services in the newest release of Visual Studio. “Visual Studio 2005 makes it real easy to step into Web Services. You no longer need to attach to the Web Service host process and set a break point to get the debugger to stop in the Web Service code. When you are debugging your client application and get to the Web Service method call, simply choose step-into and Visual Studio 2005 does the rest. Just make sure both projects are loaded in your solution.”

Bill Wagner

Wagner usually sticks with defaults for his debugging environment; however, he has two configurations for specific scenarios. “If I’m working on any code that uses large arrays (typically numerical analysis), I’ll dock the watch windows to the side of the workspace, rather than the bottom. Also, if I’m debugging drawing code, I’ll set the debugger and the debuggee side by side so I can see the effects of the drawing code, and not generate new paint messages by laying the VS window over the debuggee.”

Wagner also offers a suggestion for working in the debugger. “Create an object ID for tracking an object quickly. I’ll use this in many scenarios, but the overriding reason is when I’m looking data that is buried inside some container: For example, when I need to keep track of one particular object in a collection. By right-clicking on a data object when a breakpoint is hit, you can assign an object ID to the object. Then, you can refer to that object in the watch window. It’s much easier to type ‘1#’ rather than myCollection.GetAt( rowIndex*rowLength + colIndex ).”

Wagner’s most important tip? “Subscribe to Jim Gries’s blog: http://blogs.msdn.com/jimgries/default.aspx He’s always got an incredible amount of information on tips you never know you could do with the debugger.”

VISUALIZERS

Visualizers are one of the greatest new features in Visual Studio 2005. They enable developers to actually understand data in the debugger instead of having to struggle through undecypherable information when viewing something like a DataSet via the Watch window. Developers can write their own visualizers for VS2005. I wondered what visualizers these pros were hoping someone would come up with.

Gregory would like to see a DataAdapter visualizer, and also has an idea for a fun, if not overly useful visualizer. “Wouldn’t it be cool if you could play streaming audio or video? But I wouldn’t use it in real life.”

Exceptions are something Avery would like to see someone write custom visualizers for. “I want to see an improved view for Exceptions. While the new dialog is nice, it doesn’t help you when dealing with inner exceptions. I would love to see a visualizer that allows you to easily dig through the inner exceptions and perhaps even some better styling on the stack trace.”

Hanselman would like to see “An XmlSerializer visualizer that takes any object and displays what it will look like when serializer. DotNetDan has a nice visualizer for Data up on http://www.codeproject.com/csharp/DataDebuggerVisualizer.asp and up on Project Distributor http://www.projectdistributor.net/Projects/Project.aspx?projectId=91 but he hasn’t updated in a while. Maybe he can be pressured by his peers.”

Wagner’s looking for better graphics support: “I’d want to be able to examine image data much more effectively. I want to look at a bitmap like the zoomed mode in the image editor, and roll over a pixel to get the RGBA values.”

“In-memory representation of an object model (with reference counts)” is a visualizer Osherove would like to see. He’s added his own contribution to the mix: “I’ve created my own collection of Debug Visualizers for Regular Expressions. You can download them here: http://regex.osherove.com.”

Osherove also points out a useful DataSet Quick Watch for Visual Studio 2003 which functions much like a DataSet visualizer in VS2005. The addin can be downloaded from Code Project: http://www.codeproject.com/csharp/DSWatch.asp.

I’ve written an earlier article here about using the keyboard to navigate around Visual Studio.  I’m a nut for not having to move my hands to grab the mouse for tasks which could be done via the keyboard.  Reaching for the mouse busts up my train of thought and slows me down, neither of which I care for.

For this installment of Ask The Pros I thought it would be interesting to get feedback from industry leaders on what their most-used and favorite keyboard commands are.  Contributors to this round of the series are:

• James Avery, Principal of Infozerk, Inc., author of Visual Studio Hacks, and host of this website
• Dave Donaldson, President/CEO of Arcware, Inc. and creator of CodeKeep
• Mike Gunderloy, Owner of Lark Group, Inc., publisher of The Daily Grind, and prolific author
• Scott Hanselman, Chief Architect at Corillian Corporation, a leading provider of eFinance solutions
• Roy Osherove, Principal of Team Agile located in Israel, and a consultant for Agile software development and .NET Specialist

Keyboard Shortcuts

James Avery is an unabashed nut for Intellisense.  “If there was a steel cage match of keyboard shortcuts there would be one clear-cut winner: Ctrl-Space. Sure there are other useful shortcut keys, but Ctrl-Space makes one of Visual Studio’s most useful features even better; it summons Intellisense wherever you are.”  Avery lists off several of what he considers Intellisense’s best uses: “Sitting on a blank line of code? Ctrl-Space will bring up Intellisense.  Want to see all your private member variables? Enter your prefix (_, m_, etc) and then hit Ctrl-Space, now you have a nice filtered list.”

Avery notes an extremely useful, but often overlooked bit of goodness when trying to find method documentation with Intellisense, “Most people will delete a comma or opening parenthesis to see the method documentation, but you can simply Ctrl-K, Ctrl-P.”

Scott Hanselman likes the very basic keystrokes supporting Copy/Cut/Paste within Visual Studio.  “I’m pretty much a CtrlX,C,V person along with Shift-Ctrl-B within Visual Studio.”  He goes off the deep geekiness end, though, by having tacked on an Ergodex input system to “map more complicated combinations (because I can’t hold them in my head) to a single custom labeled button.”  Hanselman wrote a blog post describing his use of the Ergodex and how its mapping ability may transform his work.

Hanselman pointed out great keyboard shortcuts outside Visual Studio which can bring great boosts in productivity.  “I’m all about the Windows Key, using Windows-Q to bring up SlickRun from Bayden Systems. In Word I tend to do Alt-V,U,Alt-VZ,T,Enter very quickly to show documents full screen for presentations. In Windows I use Ctrl-Space,N to minimize a lot, and in the Command Prompt I use Ctrl-Space,E,P and for pasting directly to the command line.”

In a bit of useful advice for folks trying to fend off carpal tunnel syndrome, or any of the other various repetitive motion injuries, Hanselman says, “I try to stay balanced in my use of the keyboard vs. the mouse.”

Dave Donaldson points out another little-known shortcut that boosts productivity for folks working in Test Driven Development environments: “Ctrl+M, K – Generate Method Stub (VS 2005).  As someone who uses a test-first approach in development, the ability to write a unit test and then hit Ctrl+M, K to generate the signature of my implementation method is rockin. It’s something that most people don’t know is there, but I find a killer shortcut in a TDD environment.”

Reading someone else’s code is something everyone has to do, and it can be an infuriating task, especially if the person who wrote the code had different conventions and styles than you.  Visual Studio 2005’s ability to format code with different styles is a terrific feature, especially since you can quickly format a document in your style: “Ctrl+E, D – Format Document (VS 2005).  I look at tons of code that is not mine, and having a quick way to format the code according to my settings is very useful. For instance, I like my opening curly brace on the next line of the method signature. However, if I look at someone’s code who types with the opening curly brace on the same line of the method signature, I simply hit Ctrl+E, D to format the code file using my settings.”

[For more information on how to set formatting options in Visual Studio, see James Avery’s Tip on C# Code Formatting.]

Donaldson’s next tip is in the same code reading line: “Ctrl+M, P – Stop Outlining (VS 2005, VS.NET 2003).  As useful as code regions are, there are times when I just want to expand all regions to scroll through the code. To do this, I hit Ctrl+M, P to turn off outlining, which expands all the regions.”

Donaldson finishes off with something near and dear to every developer’s heart: “F5 – Start Debugging (VS 2005, VS.NET 2003, and previous versions).  Enough said.”

Roy Osherove starts off with a favorite of mine, the Clipboard ring.  “The clipboard ring is not very well known, but very powerful:
Pressing Ctrl-Shift-V repeatedly pastes in the last ten “Copy” operations you’ve made, saving you precious time.” He also notes that “Ctrl-Alt-X: the tools window (which allows you to see the Clipboard ring in vs 2003). Pressing Ctrl-DownArrow and UpArrow shifts between the open tools tabs in that tool window.”

Moving around to spots in the editor windows you’ve been is made simple by using “Ctrl–(minus) and Ctrl-Shift–: gets you back and forth in the location history of the editor.” Osherove points out another useful movement keystroke:  “Escape – useful. Always makes the code view or current document in the tab active, no matter what tool window is active at the time.”

Two quick keystrokes save Osherove time when bouncing to specific windows.  “Ctrl-Alt-S brings up the server explorer,” and “Ctrl-Alt-O: the output window.”

Osherove’s last tips deal with working with code in an editor window.  Commenting out blocks and un-commenting them again are serious drudgework greatly eased by “Ctrl-K-C and Ctrl-K-U to [C]omment and [U]ncomment code blocks.” Finally, “Ctrl-Shift-Space – shows the parameter list for a method call. Saves the time going back, deleting and reentering a command after the last parameter. Phew! (If you have resharper installed, it’s Ctrl-P.”

Macros

Macros don’t seem to have much regular use with this round’s responders.  Perhaps macros aren’t particularly useful in day-to-day work and just solve occasional tricky problems. Hanselman notes “I have lots of macros, but they are the kind that you use once in a blue moon. I haven’t any macros that I use daily.”

Keybindings

Avery’s favorite keybindings involve wiring up a great addin to Visual Studio: Roland Weigelt’s GhostDoc.  “Nothing like having the commands on keystrokes to make that useful add-in even more useful.”

Many Visual Studio developers might not realize how many shortcut commands are available to them for custom binding.  Osherove gives some great advice.  “The best thing you can do for yourself is look at all the currently available shortcuts by clicking Tools-Options-Keyboard and looking for whatever command you like. You can also map shortcuts to any command (or multiple shortcuts to a single command).”

And Finally

Not all highly-skilled developers are fixated on making the most of the keyboard.  Gunderloy spends his days using a tremendous number of tools.  So many, in fact, that he doesn’t take time to learn shortcuts.  He says “If it wasn’t for typing code, I’d never touch the keyboard at all. I know it puts me at odds with most experts, but I drive the UI with the mouse, period. I can’t be asked to learn keyboard shortcuts or set up custom key bindings; I spend too much time switching between too many different programs all day long.”

Visual Studio 2005 includes a huge amount of new functionality ranging from code snippets to refactoring.  But does it get everything done that everyone wants?  Of course not.  As Steven Wright says, “You can’t have everything.  Where would you put it all?”  Some industry leaders don’t want everything, but they’ve got some great ideas on a few things which should be added into the next version of Visual Studio.

Contributors to this round of the series are:

• James Avery, Principal of Infozerk, Inc., author of Visual Studio Hacks, and host of this website.
• Ben Carey, Senior Consultant at Statera Consulting in Denver Colorado
• Kate Gregory, founding partner of Gregory Consulting Limited
• Bill Wagner, Founder/Consultant with SRT Solutions and author of “Effective C#”

Ben Carey says, “Overall, I’ve been very happy with the new version of Visual Studio, but there are a few enhancements and new features that I would like to see in upcoming versions.”  It’s not surprising that Carey, who emphatically listed ReSharper as his favorite add-in for an earlier Ask The Pros installment, wants to see “additional named refactorings. I love the new refactoring support, but there are many additional refactorings that I use frequently that I would like to see integrated into Visual Studio.”

Carey would also like to see some performance improvements in the refactoring area. “I’m also hoping that many of the refactorings get faster in future releases. It seems that a handful of the refactorings could perform drastically faster just by taking into account how their respective items are scoped.”

Better integration for MSBuild rates high on Carey’s list, too. “I would also like to see better IDE support for MSBuild. It’s great that we have MSBuild as a foundation, but the IDE support is lacking. I’m comfortable modifying the XML directly, but I would like to have visual tools to orchestrate the build process (especially in the context of multiple projects and custom targets).”

James Avery would like to see one feature which Eclipse, a well-known Java development environment, supports: “I would love to see support for automatically updating add-ins. This is one of the features from Eclipse that I think is very cool. You can simply enter a URL and the add-in will be downloaded, then when there are changes it can be set to automatically keep it up to date.”

Like Carey, Avery would like to see improvements in Visual Studio’s refactoring functionality. “I would also like to see even more support for refactoring, perhaps even a templating solution, especially one that is a little bit quicker. The current refactoring sometimes takes just as long as doing the job manually would. Speaking of refactoring I think its time that the Extensibility Object Model got a good working over, currently it is pretty hard to use without keeping the documentation close at hand. It would also be nice to have a new source control interface that supported edit/merge/commit.”

Finally, Avery thinks “A C# automation solution would also be nice, either Macros or some combination of Macros and templates would be excellent.”

Bill Wagner, who gave great debugging tips in an earlier ATP article, wants better debugging support.  “I really want to see some fine-control over thread context switches.  Debugging possible race conditions is especially tricky, and reproducing them in a debugger environment is even more so.  I’d like the ability to tell the debugger to execute a thread switch at a particular statement, and to switch back again at a particular statement in that thread.”

Wagner, who admits he “still finds multi-threaded programming a bit of a pain,” is very clear about the benefits of such an improvement: “It would make it much easier to verify bugs that show up only with certain race conditions.  Once those are verified, it would make the fix easier to verify as well.”

Kate Gregory follows up her previous tips on debugging with ideas for improving team development communications: “I want to be able to right-click a line of code and select ‘Who wrote this?’. I know that information should be in the source control system, and I want it! On a multi-developer project, some code is so awful you must immediately know who to find and beat— ah, have an open and frank exchange of views with.”

Spell-checking and Intellisense support in comments rates high for Gregory.  “This would actually be pretty tricky to implement because if I use a variable name in a comment I would like intellisense to help me on that, but at the same time I want an office-like autocorrect to handle things like separate/seperate or variable/varible that certain devs in my shop are constantly getting wrong.”

Lastly, Gregory would like Visual Studio to have more assistance when developing for SharePoint. “It’s pretty much the last kind of work where I need to have several other windows (a command prompt, some windows explorer windows for file copies, the gac, …) open as well as Visual Studio.“  She admits her wish list for that particular feature area is “a bit too long” for an Ask The Pros article…