Category

Debugging

TypeLoadException_ExceptionWindow

This issue stroke me suddenly and without any reason (at least I couldn’t find one). One day code that rotates picture, which was captured from camera, started to throw exceptions. I was really surprised, because I didn’t change much in the project since the time it was working just fine..Till this day, I have no idea what was the cause of it

TypeLoadException_RotatingPictureCode

What I figured out after some research on the Internet and looking in the generated *.appx package files (appx ~ zip – by changing extension of your *.appx to *.zip you can check what’s in it)  I discovered that for some reason the AppxManifest.xml was lacking entry with the title library mentioned in the title of this blog post (highlighted entry is the one that was missing and had to be added manually)

I couldn’t work it out how I can force mechanism standing behind creating packages (*.appx) to include this in the AppxManifest.xml, so the only solution was to insert it after package was made. To automate this process, of unpacking files from *.appx package, making amendments to the AppxManifest.xml and then repacking again all the files into *.appx pckage, I wrote a pretty ‘nasty’ PowerShell script which uses makeappx.exe (to unpack and repack) and some other PowerShell ‘hacks’ ;]

In the end, all this script does is inserting one line of code into your AppxManifest.xml file, which is

After executing this script, your package should be ready to go, and your Lumia’s (old Nokia’s) libraries shouldn’t fail again

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:

default_disply_of_the_object_while_debugging

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:

checking_the_details_of_the_object

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.

default_debugger_display_of_objects

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

debuggerdisplay_attribute_in_action

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:

Exception_occured_dialog

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:

Exception_details_dialog

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.

Exception_in_full_details_in_watch_window

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:

Exception_complex_params_inspected_inside_watch_window

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

Exception_casting_inside_watch_window

and voilla