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.

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:

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.

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.

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.

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:

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:

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.

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.

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.

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.

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.

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.

Dr Neil on the ASP.NET Silverlight Streaming control

Myself, covering the ASP.NET Virtual Earth control

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.

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.

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.

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.

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).

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.