Actually I lied in the title, I haven’t learned it today but there was a day when I’ve stumble upon this attribute in someone’s code and started using it ever since. This is one of these things that makes your life much easier while debugging. What does this DebuggerDisplay attribute do exactly ?

Let’s start from the beginning. By default when inspecting an object e.g. House:

we will se something like this:


You can say, but that’s not so bad, because we can inspect this object in details really easily by just expanding information about it, indeed:


As you know this process, which sometimes cannot be omitted, could drive you mad, especially when you are almost at the end of expanding really complex object and then you miss clicked the last expanding arrow, so everything collapsed, and you’ve to start ‘digging’ from the beginning. Even though it could be a painful process it’s pretty straight forward to inspect whatever information you’re looking for. Things could get bit more annoying when you’re dealing with collections.


This collection is just an example, of really small one, that still could be handled by this ‘clicking and expanding’ process, but imagine a collection with tens or hundreds of elements (probably you don’t have to imagine anything ‘cause you’re deal with those on regular basis) in which you want to check some deeply hidden property of a child of a child of a child of a child of your object. That would be a nightmare. With help comes DebuggerDisplay attribute which is used as simple as writing something like this

which gives us an effect of showing whatever information you need (even the one deeply hidden inside an child of a child etc.)


Now you’re ready to use it and make your debugging life much easier. BEFORE that, though, you have to be aware of some possibilities and good practices in this subject. You can write basically any code you want in the attribute {string}. This expression is going to be evaluated and than presented while debugging. Previous chunk of code (with DebuggerDisplay attribute) is BADLY written and I’ve put it only for exampling purposes. The first BAD thing about it is that it’s going to evaluate three expressions, and evaluation costs. Second BAD thing is putting a collection indexer reference in it, which can cause exception. So how it should look like ? Like this:

The best practice for DebuggerDisplay attribute is to use as less expression to evaluate as possible and this can be achieved using one property which is going to present your object as you wish. For more specific information(and what this ‘nq‘ thing is doing in the DebuggerDisplay attribute {string}) go to this msdn blog post, which explains in details good and bad practices. It’s not so long and it’s definitely worth reading

Not so long ago I had a small problem with inspecting pretty complex exception. Usually what you see after some exception is thrown is basically this kind of window:


I’ve highlighted Break when this exception type is thrown because without this box being ticked you won’t be able to see $exception pseudovariable inside your Watch window, but about that in a second. After seeing that, usually you click on View Details to check what exactly had happened:


Inspecting all of the provided information doesn’t give you much more information about Exception itself besides the type of it and that there are some more specific information inside the Exception (two exception parameters). Even though we don’t have much information about ‘insides’ of the exception we can tell something from exception name itself, right ? That’s correct, you can figure out what kind of exception or with which group of exceptions you’re dealing with, but you still don’t have specifics. With help comes mentioned earlier $exception pseudovariable.


As you can see there’s a lot information about exception that was thrown. For us the most important part is kept inside ConsoleApplication1.ComplexException:


Now you know exactly what had happened. You can do a little tweak around displaying it in the Watch window, so you won’t be bothered by other properties of Exception object. Just cast $exception to specific Exception type, like so


and voilla

Recently I’ve been doing some work with ASP.NET MVC, going back to the roots ;]. I had to create simple Web Portal to manipulate database tables. It had to have possibility to make CRUD (Create, Remove, Update and Delete) actions on tables records. I used MVC scaffolding option with specified model. After few clicks everything was generated for me, I mean Controllers and Views. Of course it wasn’t exactly as it was suppose to be, so I had to apply some changes. Making these changes I’ve realized that not everything is correct when it comes to models. Applied changes to models forced changes on the Views. In that moment I could just generate everything again but changes were only minor so it would take more time to make the ‘clicking’ than dealing with these changes on my own. What I’ve done to the models was simply deleting some properties. Everything look ready to compile, so I’ve tried. Errors occurred. Obviously, property that I’ve just removed from the model was used somewhere in the code and now compiler can’t find it’s representation. I’ve removed all of the problems and I finally could check how does the website look like in the browser:


Of course..yellow page of death showed up ;] There were still some references in the Views aka *.cshtml files that should be cleaned. One change, refresh page, another error, second change,  refresh page, another error, … , tenth change and so on and so on. So is there a way to put some guard or sentry to keep your Views compilable ? Yes there is! There is a big cost, though, that comes with it. Your build time will increase dramatically, but you can pretty easily switch it on and off whenever you need it. After major changes to your models just build it once with this function turned on, catch all the errors and switch it off afterwards.

What you have to do to get your Views to be compiled is rather straightforward. You need to change *.csproj file. You can do it in two ways. One is from Visual Stuido and the second just usual file edition from File System (Explorer). We will do it with VS. Let’s get this party started. First we have to unload our project so the *.csproj file could be edited.


After unloading, we’re going to edit our project file like so:


Now we should see *.csproj file and this is the place where we can force compiler to build our Views along with the code. All we have to do is to change MvcBuildViews setting to True or if the entry is missing just add it


Now you should see your compilation errors inside Error List window in Visual Studio

compilation_error_on_the_viewI’ve noticed that with MVC 5 this solution isn’t working, and what I’ve found out is that you need to add some extra stuff. In the same project file that you’ve been editing recently, at the very end of it, uncomment element

and add this code

You can read more about this topic on