OzCode: Reveal With Reveal

In my last post, I revealed that I am a magician; an OzCode magician1. I also revealed the new LINQ support currently in EAP. Since that was two reveals in one, I thought that I would look at another OzCode feature today coincidentally called Reveal.

I remember this specific feature as "favourites for properties" although I am reliably informed by the OzCode team, their website, and their documentation that it is in fact called "Reveal"2. Reveal was the feature that first lured me into regular use of OzCode and if it is the only feature you use, you will still wonder how you really survived without it.

When debugging, we can spend lots of time drilling down into objects to find the value of various properties and sub-properties. This can get especially tiresome when we're looking at a few similar objects since we repeat the same steps. Although pinning certain values is helpful, it does not really solve the initial issue of drilling down to find the thing to pin.

With Reveal, we can make life much simpler by elevating the details of an object to its summary; like an on-the-fly custom ToString implementation. Not only does this help with looking at one item, but it really helps with collections of similar items. For example3:

Animated GIF showing how to use Reveal in OzCode
Animated GIF showing how to use Reveal in OzCode

Any properties that are "revealed" carry across to the rest of the debug session and beyond; once you have revealed some properties, they stay revealed until you decide you do not want them to be anymore, even across debug sessions.

Animated GIF showing how the revealed properties remain revealed
Animated GIF showing how the revealed properties remain revealed

You can even see (and change) your revealed properties directly within the LINQ analysis window.

Animated GIF of using Reveal inside the new LINQ analysis feature of OzCode
Animated GIF of using Reveal inside the new LINQ analysis feature of OzCode

Finally, revealed properties propagate up the object hierarchy allowing you to surface values from deeper in your object tree. This can really be a huge time saver, especially since the revealed properties are remembered across sessions. No more hovering over multiple things to find what you're looking for and no more writing custom ToString overrides, debug visualizers, or other workarounds.

Hopefully, this overview of Reveal in OzCode has demonstrated not only why I love it so much, but also how valuable it can be. I genuinely believe OzCode to be an essential tool in any .NET developer's kit, but since you may mistake me for some corporate shill, you should not take my word for it; try OzCode out for yourself with a free trial (or take part in the EAP). Stop performing workarounds and start performing magic.


  1. Read as Sean Connery as James Bond 

  2. and apparently it doesn't matter how often I tell them they are wrong 

  3. To demonstrate, I am using the handy demo app from OzCode, which you can find on GitHub 

I Am an OzCode Magician and I Have a New LINQ Trick

It has probably not gone unnoticed by those whoocm_logo know me that I really like the OzCode extension to Visual Studio. Now, I have an awesome glass brick with my name etched in it as proof1. I am happy to announce that I was recently invited to be a part of the OzCode Magician Program; an award in recognition of my genuine enthusiasm and support for OzCode over the last couple of years.

linqBug

What I really like about this is that I get to occasionally preview a new feature or two. Of course, sometimes I will be sworn to secrecy on what those features are, but thankfully, the current feature I have been allowed to play with is no secret at all. It was showcased in OzCode's recent webinar and recently made publicly available as an EAP2, so you can try it too. To whet your appetite, here is a sneak preview of the new magical LINQ debugging support.

numericIndicators

In this latest update to OzCode, we get some really nice visualizations of our LINQ queries, enabling us to see the queries step-by-step. No more refactoring code just to see what that Where will do.

quickDatatip

The new LINQ debugging allows a user to step into a specific part of the query chain on a specific iteration and see exactly what the outcome is, and it can show you how inputs map to outputs on many of the most common LINQ operations.

detailsQueryToolWindow

At the time of writing, the EAP only supports fluent syntax LINQ but I am assured that query syntax support is on its way. So, go register for the EAP now and give it a try for yourself. It's magical!


  1. also weighty enough to be a prop in an episode of CSI 

  2. Early Access Preview 

C#6: The nameof Operator

Before discussing the nameof operator in C#6, I want us to consider why nameof exists at all. So, let's head back ten years to the heady days of 2005.

Wayne's World Flashback

When version 2.0 of the .NET framework arrived, it transitioned the fledgling platform from a sketch of what might be to a fully-formed platform that could support ongoing and future desktop and web development. Since then, each release of the framework and its associated languages have added a variety of bells and whistles that simplify and enhance the way we develop. Among many of the concepts and types introduced by .NET 2.0 was System.ComponentModel.INotifyPropertyChanged, part of the enhanced data binding introduced to Windows Forms development. This interface turned out to be a workhorse and introduced many developers to a new problem; making sure the string that named a variable matched the name of an actual variable.

Now, you may well object to this claim since various versions of ArgumentException already demanded this of developers, but I think we both know that until our tooling got smarter (like FxCop and Resharper), many of us just did not fill that argument out if we could help it. After all, the stack trace would tell us where the crash happened, we could put something meaningful in the exception message, and keeping that variable name up-to-date after refactoring was a pain. With the advent of INotifyPropertyChanged the benefit of putting the variable name in a string started to outweigh the costs. Quickly, patterns emerged to try and simplify this, from dubiously performant uses of reflection to build-time code generation. As tools matured, we could get refactorings that took these strings into account and warnings that could shout at us if a variable was mentioned that didn't exist. Few of these were particularly elegant or entirely foolproof, and none were both1. In addition to ArgumentException and INotifyPropertyChanged, property names would be used for logging and debugging.

In the Name of Progress

There were calls for a new operator to accompany typeof; the new operator, infoof2 would provide the corresponding reflection information of a particular code construct (like MethodInfo or PropertyInfo), simplifying not just obtaining the name of something, but also any reflection operation involving that something. All this use and discussion of meta-information did not go unnoticed. Eric Lippert blogged about infoof and why it would be useful, why it was so difficult to implement, and indirectly foreshadowed where we would be today. However, amid the discusson, there was little action.

In 2012, .NET 4.5 brought us the CallerMemberNameAttribute type and its siblings, CallerLineNumberAttribute and CallerFilePathAttribute. These new attributes enabled developers to decorate method arguments, indicating that the appropriate piece of information was to be injected into that argument when the method was called. This fell short of an infoof operator, but it greatly simplified use of INotifyPropertyChanged (and INotifyPropertyChanging, introduced in .NET 3.5). Alas, argument exceptions, logging, debugging, and other uses of method, variable, and property names were left as they were, often leading to mismatched error messages, obscure data binding bugs, and other problems.

That changed in 2015 with the new releases of both .NET and C#, and the new nameof operator in C#6. The nameof operator is sublimely simple; in fact, its concept seems so obvious that it's a wonder it took so long to appear3. Using nameof, we can inject the names of variables, types, methods, events, and properties into all sorts of places at compile-time4, knowing that if we change the name, our refactoring tools can update all references with confidence. Not only that, but our intent is clear; we want the name of this thing to be here and not just some string that happens to look like the name of some thing. While the nameof operator does not replace CallerMemberNameAttribute, which so deftly simplified INotifyPropertyChanged5, it does simplify other scenarios like throwing ArgumentException, logging errors, and outputting debug information.

In Conclusion

When I first contemplated writing a whole blog entry dedicated to nameof, I thought it was too simple a feature to warrant such focus; now I have finished, I believe nameof to be entirely worthy of the attention. Along with the fantastic string interpolation in C#6, I believe nameof is one of the simplest and most useful additions to the C#6 language. Like many C# and .NET features we now take for granted, nameof is a beautifully simple concept that we will come to rely upon. I believe it will save us countless hours of fixing erroneous refactoring, arguing over coding style and code reviews, and head-scratching at spurious errors.


  1. IMHO 

  2. pronounced, "Info Of" 

  3. As is often the case in software development, we were all too busy discussing the most complex use-case we could think of rather than the one that really needed solving 

  4. unlike reflection-based solutions that do all the work at run-time 

  5. nameof does provide an alternative, more wordy alternative for that scenario 

C#6: Auto-property Initializers and Expression-Bodied Properties

Last week, I discussed the new null-conditional operators added in C#6. This week, I would like to discuss two features that are awesome but could lead to some confusion: auto-property initializers and expression-bodied properties1.

Auto-initialized Properties

Before C#6, if we wanted to properly define an immutable property that had some expensive initialization, we had to do the following2:

Some people often use the shortcut of an auto-implemented property using the following syntax:

However, defining properties like this means they are still mutable within the class (and its derivations). Using a backing field with the readonly keyword not only ensures that the property cannot be changed anywhere outside of the class construction, it also expresses exactly what you intended. Being as clear as possible is helpful for anyone who has to maintain the code in the future, including your future self.

From what I have read and heard, the main driver for using auto-implemented properties was writing less code. It somewhat saddens me when clarity of intent is replaced by speed of coding as we often pay for it later. Thankfully, both can now be achieved using initializers. Using this new feature, we can condense all that code down to just this:

It is a thing of beauty3. Behind the scenes, the compiler produces equivalent code to the first example with the readonly backing field.

Of course, this doesn't help much if you need to base your initialization on a value that is passed in via the constructor. Though a proposed feature for C#6, primary constructors, would have helped with this, it was pulled from the final release. Therefore, if you want to use construction parameters, you will still need a backing field of some kind. However, there is another feature that can help with this. That feature is expression-bodied properties4.

Expression-bodied Properties

An expression-bodied property looks like this:

This is equivalent to:

Using this lambda-esque syntax, we can provide more succinct implementations of our read-only properties. Consider this code:

Using expression-body syntax, we can write it as:

But for the additional backing field declaration, this is almost as succinct as using an auto-implemented property. Hopefully, this new syntax will encourage people to make their intent clear rather than using the auto-implemented property shortcut when implementing immutable types.

Caveat Emptor

These new syntactical enhancements make property declaration not only easier to write, but in many common cases, easier to read. However, the similarities in these approaches can lead to some confusing, hard-to-spot bugs. Take this code as an example:

Here we have two properties: CurrentDirectory1 and CurrentDirectory2. Both seem to return the same thing, the current directory. However, a closer look reveals a subtle difference.

Imagine if the current directory is C:\Stuff at class instantiation but gets changed to C:\Windows some time afterward; CurrentDirectory1 will return C:\Stuff, but CurrentDirectory2 will return C:\Windows. The reason for this difference is the syntax used. The first property uses auto-initialization; it captures the value of Environment.CurrentDirectory on construction and always returns that captured value, even if Environment.CurrentDirectory changes. The second property uses an expression-body; it will always return the current value of Environment.CurrentDirectory, not the value of Environment.CurrentDirectory on construction of the MyClass instance.

I am sure you can imagine more serious scenarios where such a mix-up could be a problem. Do you think this difference in behavior will be obvious enough during code review or when a bug is reported? I certainly don't and I'm writing this as a way of reinforcing it in my own mind. Perhaps you have already dealt with a bug relating to this; if so, share your tale of woe in the comments.

In Conclusion..

I am by no means intending to discourage the use of these two additions to the C# language; they are brilliant and you should definitely add them to your coding arsenal, but like many things in software development, there is a dark side. Understanding the pros and cons of any such feature is important as it enables us to spot errors, fix bugs, and write good tests. This new confusion in the C# world is just another encouragement to code clearly, test sensibly, and be aware of the power in the tools and languages we use.


  1. No one else seems to by hyphenating "expression-bodied" but it doesn't make sense to me otherwise; what is a "bodied property"? 

  2. Yes, I know that System.Enviroment.CurrentDirectory isn't really expensive; this is for illustrative purposes 

  3. especially if you are keen on making sure your code expresses exactly what you mean 

  4. expression-bodied methods are also possible, but I'm not touching on that in this post 

Tracepoints, Conditional Breakpoints, and Function Breakpoints

We've all been there: we step through our code with breakpoints and it works just fine, but run it without ever hitting a breakpoint and our code explodes in a fiery ball of enigmatic failure. Perhaps the failure only happens after the 1000th call of a method, when a variable is set to a specific value, or the value of a variable changes. These bugs can be hard to investigate without actually modifying the software that has the bug, which then means you are no longer debugging the same software that had the bug and might mean the bug disappears1.

Thankfully, Visual Studio has our backs on tracking down some of these more obscure bugs. Visual Studio allows us to modify our breakpoints to only break on certain conditions (like the 5th loop iteration, or when a file is open), to output text to the debug window, or to just output text and not actually break into our code. We can even create breakpoints that break on any function that matches a name we provide, just in case you don't even know which code it's actually calling.

Though I discuss the 2015 experience, the features themselves have been around for quite some time. I would not be surprised if this were the first time you had heard about these breakpoint settings, they have always been somewhat hidden away from the primary workflow. Even now, with the updated user experience, they are not obvious unless you go exploring.  If you want to see how to use them in your variant of Visual Studio, or get more information on breakpoints in 2015, MSDN has you covered (2003|2005|2008|2010|2012|2013|2015).

Conditions and Actions

Floating breakpoint toolbar

Let's begin by taking a look at adding conditions and tracepoints. When you add a breakpoint to a line of code, either by using the F9 keyboard shortcut or left-clicking in the code margin, a little toolbar appears to the upper right of the cursor2 . The toolbar has two icons: the first is called Settings…, where all the cool stuff lives; the second is called Disable Breakpoint, which is very useful if you have customized the breakpoint3. If you click the Settings… button, you will see an inline dialog with two checkboxes; Conditions and Actions4.

If you check the first box, Conditions, you will be presented with various fields for specifying a condition under which the breakpoint fires. There are three types of condition;

  1. Conditional Expression
  2. Hit Count
  3. Filter
Adding a condition to a breakpoint
Adding a condition to a breakpoint

Conditional Expression conditions allow you to specify a condition based on variables within your code. You can break on when a specific condition is met, or when a condition changes (this allows you to break when a variable changes value, for example).

Hit Count conditions allow you to break once after the breakpoint has been hit a specific number of times (such as on the fifth index of an array in a loop), every time after the breakpoint has been hit a specific number of times, or every time the hit count is a multiple of a specific number (like every other hit, or once every five hits).

Filter conditions allow you to specify filters based on process, thread, and machine names, and process and thread identifiers.

Conditional breakpointYou can add multiple conditions to a breakpoint, which all have to match for the breakpoint to fire. When a condition is applied to a breakpoint, the red circle will have a white plus symbol inside it.

Adding output text to a breakpoint
Adding output text to a breakpoint

If you check the Actions box, you can specify text to be outputted when the breakpoint fires. By default, a checkbox named Continue Execution will be checked because, usually, if specifying output text, you want a tracepoint rather than a breakpoint. However, if you want to break and output text, you can uncheck this additional checkbox.

Non-breaking breakpoint (aka tracepoint)When a breakpoint is set to continue execution, the red circle changes into a red diamond. If a condition is also applied, the diamond has a white cross Conditional non-breaking breakpoint (aka tracepoint)in it.

If you use the Oz-code extension for Visual Studio, tracepoints are given some additional support with a quick action to add a tracepoint and a tracepoint viewer that shows you just tracepoints.

Function Breakpoints

Adding a function breakpoint
Adding a function breakpoint

So far, we've looked at traditional breakpoints that are set on specific lines of code. Function breakpoints are set against function names. To add a function point, use the Visual Studio menu to go to Debug→New Breakpoint→Function Breakpoint…5. Selecting this will show a dialog where you can specify the function name (qualifying it as you require), and the language to which the breakpoint applies. You can also specify conditions and actions as with any other breakpoint.

In Conclusion…

Visual Studio is a complex development environment, which unfortunately leads to some of its cooler features being harder to find. I hope you find this introduction to breakpoint superpowers useful, if you do or if you have more Visual Studio debugging tips, I'd love to hear from you in the comments.

Today's featured image is "Debugging the Computer" by Jitze Couperus. The image is licensed under CC BY 2.0. Other than being resized, the image has not been modified.


  1. yay, fixed it… 

  2. This also appears if you hover over an existing breakpoint in the margin 

  3. Deleting the breakpoint would also delete any customization, but disabling does not 

  4. This dialog can also be reached by right-clicking the breakpoint and choosing either Conditions… or Actions… or by hitting Alt+F9, C; the only difference here is that one of the two checkboxes will get checked automatically 

  5. You can also add one via the keyboard with Alt+F9, B or the New… dropdown in the Breakpoints tool window