It’s the beginning of a new year! According to Back to the Future Part II, everyone will be riding hoverboards in a couple months (and, let’s be honest, Doc would love the HoloLens). In the meantime, let’s explore the enhancements we’ve made to the Visual Studio debugging experience. In CTP 6, we improved the edits supported by Edit & Continue and now support Make Object ID in the new 2015 C# and VB expression evaluators.
Before you read more about our improvements in CTP 6, make sure you have read Anthony’s post on debugging improvements in Visual Studio 2015 Preview.
Edit & Continue is reaching its potential.
Edit & Continue lets you modify and add to your source code while debugging without ever having to restart your session. I’m happy to say we listened to you all and have fleshed out the Edit & Continue experience. Say goodbye to the days of pre-2005 language support and small edits! See the list below to see what source code edits are possible while debugging*:
- Adding methods, fields, constructors, properties, events, indexers, field and property initializers, and nested and top-level types (including delegates, enums, interfaces, abstract and generic types)
- Modifying bodies of constructors (including constructor initializers), expression-bodied members, and field and property initializers
- Adding and modifying methods that use the following post-2005 types and features:
- Reordering type members and type parameter constraints
- Refactoring code (extract method and inline temporary variable) using
Ctrl + .
*The following types of edits are not supported:
- Deletion of members, types, or entire method bodies
- Modifying method signatures and renaming
- Modifying generics, interfaces, and abstract types
- Adding or modifying enum members to an existing enum
- Modifying await expressions wrapped inside other expressions (e.g.,
Object IDs are a hidden gem and we’ve modified the syntax.
Did you know you can tag an object in the debugger and refer to it later using Make Object ID (even when the object is out of scope)? Did you know you could compare references of objects and verify that they refer to the same object with an Object ID tag? While Object IDs have been around for several years, few know and take advantage of this feature.
An Object ID is a unique identifier for an object. Because garbage collection unpredictably shifts object memory addresses, we can’t use pointers to track objects. Instead, our debugger gives you a unique identifier and keeps track of the object’s current location for you (using an aliasing mechanism in the CLR). You can use the Object ID when debugging to compare references of objects and be absolutely certain they refer to the same object. You can also use an Object ID to monitor an object when it is out of scope in the debugger.
Below, I am stopped at a breakpoint on line 13. I have created a Watch for
Circle a and made an Object ID for it (
$1). Now if I step into the initialization of
Circle b, putting
Circle a out of scope, I can still inspect the value of
Circle a via its Object ID:
Another change to note is that we’ve changed the Object ID syntax for C# and Visual Basic. It is now a dollar-sign ($) followed by a numeric for both languages (e.g.,
$1). The previous syntax for Object IDs was
[number]# for C# (e.g.,
ObjID[number] for Visual Basic (e.g.,
ObjID1). We chose to alter the Object ID syntax for the following reasons:
- The new syntax will allow us to provide a better IntelliSense experience by showing defined Object IDs in the completion list after typing the “$” prefix character (planned for RTM)
- The new syntax is now consistent with other pseudo-variables, (e.g.
Over ‘n’ out
Kasey Uhlenhuth, Program Manager, Managed Languages Team