Professional Visual Studio
Tips, Tricks, and Best Practices for professional .net developers

Yesterday Microsoft Visual Studio Extensibility team announced a new update in Visual Studio 2008 SDK and released version 1.1 to public.

For VSX developers, this is important news because there are some major updates to improve the extensibility features especially around Visual Studio Shell development. This new version works on .NET Framework 3.5 and Visual Studio 2008 Service Pack 1.

Quan To has outlined these updates on VSX team blog but major updates are a reduction in the size of VS Shell package installers that no longer hold .NET Framework 3.5 data and also there is an update that lets you develop VS Shell applications as a normal Windows user that wasn’t possible before.

You can download Visual Studio 2008 SDK 1.1 from here.

Hands up if you think the Output window is annoying in its default configuration. I’m referring to how every time you run a build the Output window pops up and interrupts you, obscuring half the code window. Sometimes I get the feeling that it was starved for attention as a child ;-)

Output Window in the way

There are a couple of easy solutions to this problem. Firstly, you can simply stop the Output window from being automatically shown during a build. Open the Options dialog (Tools->Options) and select Projects and Solutions. You will find an option under here called Show Output window when build starts. Simply uncheck this option and you will never be interrupted again.

However many people, myself included, have found that the Output window is actually quite useful to have around. If that’s the case, you may want to have it automatically open, but in a different way. My suggestion is to try changing the Output window to display as a Tabbed Document. Simply right-click on the window title bar and select Tabbed Document as shown below:

Output window to Tabbed Document

Once you’ve made this change, the Output window will open at the same level as the active code window. It will still come to the foreground, which I find useful, however to me it feels like it does this in a much more natural and frictionless way. I’d be very interested to hear whether anyone else prefers this also.

Output window as Tabbed Document

To wrap up this post, here’s a couple more things about the Output window that are useful to know:

  • Press Ctrl+Alt+O to display and bring the Output window into focus;
  • Press Ctrl+S when the Output window has focus to save the text in the Output window to an external file;
  • If you do choose to not automatically display the Output window during a build, you can redirect all Diagnostic messages (e.g. Debug.Print) to the Immediate Window, as mentioned in my first Debugging Tip of the Week.

Last week, we started to explore the first of the Debugger attributes that are found in the System.Diagnostics namespace by looking at the DebuggerBrowsable attribute. I’d like to continue that theme this week with the DebuggerDisplay attribute.

No doubt you’ve seen that hovering your mouse over a variable while you are in Break mode will cause a tooltip to be displayed, which shows the type of object you are hovering over. You can see this below, where the datatip for a Customer object is shown.

Customer class with a default datatip

Unfortunately this information is not particularly useful, as most of the time you have a fairly good idea about the type of object you are dealing with. It would be better for this single line to contain more useful information about the object, as is the case with simple types such as strings or integers where the actual value is displayed.

This is where the DebuggerDisplay attribute comes in handy. It can be used to change this single line representation of the object from the default full class name. The attribute takes a single parameter, which is a String. The format of this string can include the { and } braces, which can contain a field, property, or method that returns a value.

For example, you could apply the DebuggerDisplay attribute to the Customer class as follows:

[DebuggerDisplay("Customer {CustomerName} has {Orders.Count} orders")]
public class Customer

If you apply the attribute in this way, it will result in the following datatip:

Customer class with DebuggerDisplay attribute

If you are a C# developer, then in addition to specifying properties and methods in the DebuggerDisplay format string, you can also include a general expression within the braces. For example, the following attribute shows how you could use an expression with a ternary operator:

[DebuggerDisplay("Customer {CustomerName} has orders? {(Orders.Count > 0) ? \"Yes\" : \"No\"}")]

Which would result in the following datatip:

Customer class showing datatip with DebuggerDisplay attribute expression

One final thing to note, in addition to Classes, the DebuggerDisplay attribute can be applied to any Struct, Delegate, Enumeration, Field, Property, or even an entire Assembly.

By now you’ve probably heard that Service Pack 1 for Visual Studio 2008 and .NET Framework 3.5 has been released. You can download it as a single setup package for both Visual Studio and .NET Framework 3.5, or just for the .NET Framework 3.5. It takes a while to complete the install, so you may want to kick it off at the end of the day, rather than tie up your machine for a few hours.

If you’ve installed any beta stuff (i.e. Silverlight 2 Beta, Framework Source Code perf patch, SP1 Beta) you’ll also need to download and run the Visual Studio 2008 Service Pack 1 Preparation Tool. The installer will check for these antirequisites and prompt you to run the preparation tool if necessary.

Scott Hansleman has a nice roundup of what Service Pack 1 includes for WinForms, WebForms, and the rest the Framework.

I would particularly encourage any web developers to install SP1, as there are a large number of important fixes and enhancements specifically targeting web development. You can find a nice comprehensive overview of these on the Visual Web Developer Team Blog.

In my latest instalment of the Debugging tip of the week, I’d like to introduce the debugging attributes. These handy attributes, found in the System.Diagnostics namespace, can be applied to your source code in order to control the way the debugger steps through it. Some of the debugging attributes can also be used to customise the data tips that appear when you hover over a variable in Break mode, or view it in a Watch window.

The first attribute we will cover is the DebuggerBrowsable attribute. This attribute takes a DebuggerBrowsableState enumeration value as a parameter that determines how the member is displayed in the variable tree. In the following code snippet, the field Orders in the Customer class is set to Collapsed:

using System.Diagnostics;

public class Customer
{
   [DebuggerBrowsable(DebuggerBrowsableState.Collapsed)]
   public List<Order> Orders;
}

Collapsed is the default DebuggerBrowsableState that you would normally see in Visual Studio. If you apply this to a member then it will be displayed, but not expanded by default, as shown below.

DebuggerBrowsableState.Collapsed

The following shows the same snippet with DebuggerBrowsable set to the RootHidden value. In this case the actual Orders item does not appear as a top-level entry in the data window, just the contents of the collection.

DebuggerBrowsableState.RootHidden

Finally, the Never value will hide the member completely from the data window. This can be quite useful if you want to hide your private properties. You can see the effect of this below, where the Orders member does not appear at all.

DebuggerBrowsableState.Never

In .NET Framework 2.0, the DebuggerBrowsable attribute is only interpreted by the C# debugger and has no effect when it is applied to Visual Basic code. This limitation has been removed in newer versions of the .NET Framework.

CTP3 of the Windows Live™ Tools for Microsoft® Visual Studio® 2008 shipped last week.  This includes ASP.NET controls for both Virtual Earth and Silverlight Streaming.  The following two video-casts illustrate how you can get started with these two controls:

Dr Neil on the ASP.NET Silverlight Streaming control

Myself, covering the ASP.NET Virtual Earth control

Last week I talked about how useful the Immediate Window is during debug-mode. A less-known, but totally awesome, feature of the Immediate Window is that it can be used at design-time to test/debug your code. This is particularly useful if you are working on a particular class or method that you want to test without running the entire application.

The best way to understand this is to see it in action. The screenshot below shows a new Customer object being created in a C# project within the Immediate window.

Design Time Expression Evaluation in the Immediate Window

When you declare a new object in the Immediate window at design-time, Visual Studio will create an instance of that object. However even though it has created this object, Visual Studio will remain in design-mode (For those that are interested, it actually uses the Object Test Bench in the background). If you invoke a method or property that contains an active breakpoint, Visual Studio will change to debug mode and break at the breakpoint. Once you resume execution from the break Visual Studio will return to design-mode.

There are a few gotcha’s and caveats that you need to be aware of when performing design-time expression evaluation.

Firstly, within a Visual Basic project you can’t use an explicit variable declaration (for example, Dim myCust as Customer). Instead variables are declared implicitly using the assignment operator (for example, myCust = new Customer()).

Secondly, if you are using C#, IntelliSense is not available in the Immediate window during design-time expression evaluation. Visual Basic programmers are a little more spoilt, as they are given a limited form of IntelliSense here.

Thirdly, any statements you enter into the Immediate Window will be evaluated against whatever project is selected in the Solution Explorer. If no project is selected,Visual Studio will evaluate it against the startup project. If the code doesn’t exist is that project, you will get an error.

Finally, you can’t use design-time expression evaluation in any project that requires an execution environment. This includes Web projects, VSTO projects, Smart Device projects, and SQL projects. However as I mentioned earlier, the scope of this is per-project. Therefore, if you have a solution that contains a web project and a separate class library project for your business logic, you can use this method to test any of the business logic code.

Professional Visual Studio 2008 was officially published today and should now be in stock at your favourite online book store. If you’re an instructor at an accredited educational institution, you can request an evaluation copy from the publisher. Wrox also has a User Group Program, which allows your local user group to request a review copy of the book.

Once you get your hands on a copy of the book, don’t forget to download the associated source code from Wrox.

We’re also excited to announce that Wiley Publishing have advised us that it will be translated into Simplified Chinese. We will update you as soon as we hear any further information on the availability of that version.

We’ve requested some promotional copies from the publisher to give away to the readers of this website. The details of this are still being worked out, as we are hoping to ensure that it’s not limited to U.S. residents only. Stay tuned for more information on this in the near future.

We sincerely hope you find Professional Visual Studio 2008 to be a useful resource. We very keen to hear feedback on the book (both positive and negative), so if you have any comments or questions, please comment on a post in this blog or send us an email.

This post has been a long time coming, as I previously announced I would start this series following my user group presentation back in June. There’s a myriad of reasons why I let it go so long, however the impending release of Professional Visual Studio 2008 has kicked me into action.

For the first of what will become an ongoing weekly series of debugging tips I’d like to start off with one of my favourite windows in the whole of Visual Studio - the Immediate Window. This useful window can be used during both debugging and at design-time. The window is displayed using the keyboard shortcut Ctrl+Alt+I, or by selecting it from the Debug->Windows menu. You can also type immed in the Command window and it will display and switch focus to the immediate window.

Quite often when you’re debugging an application, you’ll want to evaluate a simple expression either to test a bit of functionality or to remind yourself of how something works. This is one situation where the Immediate window comes in very handy. This window enables you to run expressions as you type them, as shown below.

The Immediate Window

To make life easier, the Immediate window supports IntelliSense, and you can use the arrow keys to track back through the history of previous commands executed.

The Immediate window also allows you to execute any Visual Studio command. To submit a command you must enter a greater than symbol > at the start of the line. There is an extremely large set of commands available; in fact almost any action that can be performed within Visual Studio is accessible as a command. Fortunately IntelliSense makes navigating this list of available commands a little more manageable.

Nick blogged last year about aliases, which are available under both the Command and Immediate windows. One of the more well-known aliases is “?”, which is a shortcut for the Debug.Print command that prints out the value of a variable. As long as you have the Immediate window open, this is generally quicker and more convenient than bringing up a watch window, or hovering over a variable and waiting for the data tip to display.

If you start to become really dependant on the Immediate window for your debugging, you should consider enabling the option to Redirect all Output window text to the Immediate window. This option can be enabled under  Tools->Options->Debugging. Although the option says it redirects all Output window text, it will actually only redirect the debug messages (e.g. Debug.Print).

Debugging Tips and Tricks

Thursday evening I am presenting at my local .NET User Group on the topic of debugging. The title is “How to be a Debugging superhero”, and for the session I will be covering as many Visual Studio 2008 debugging tips, tricks, and best practices as I can fit into an hour. It should be a fun session (100% hands on) and I’ve also got a bunch of swag to give away, courtesy of the Microsoft Heroes {Community} Launch program.

For those who can’t make it to sunny Perth for the session, as of next week I will be starting an ongoing, weekly series of blog posts covering all of the debugging tips and tricks that I can lay my hands on. I wrote 5 chapters on debugging in our upcoming Professional Visual Studio 2008 book, so there is plenty of material for me to draw from.

Next Page »


About this site

Professional Visual Studio aims to provide tips and tricks, traps to avoid, and industry best practices from experienced .NET developers on using Visual Studio in the most effective way possible.

Copyright © 2007-2008 David Gardner, Keyvan Nayyeri, and Nick Randolph. All rights reserved.
Blog | Archives | Books | About | Contact