c#

A customized shortcuts scheme for an improved debugging workflow in Visual Studio

Posted on by kjartan

Update: I just realized I’d forgotten one of my favorite shortcuts: Alt + N. So what does it do? See the list below! Suffice it to say, after using it I no longer worry about getting lost in tangent code while debugging. 😉

I love a good shortcut. I love it when I can perform a task without removing my hands from their regular location on the keyboard, and without having to look down to find that one special hard-to-reach key. Now as every moderately experienced programmer knows, debugging is often an essential part of the job. In fact it can sometimes take up the clear majority of your time for extended periods. That’s why I’ve always found it so strange that the shortcuts for regular debugging actions such as step over, step into, step out of and so on have such (in my opinion at least) impractical shortcuts.

The following is a scheme of key bindings that I have been using for two or three months now, and which I find natural and easy. The effect of this change has been bigger than I had anticipated: Since I no longer need to pause to look down at the keyboard while stretching for the F11 key for example, my train of thought is slightly less prone to being interrupted. Cutting out these minimal context switches means I can focus better on the code, which means I work faster and spend less mental energy keeping track of where I am, and what is going on — and there’s your improved debugging workflow.

(*) shift + F11 is a common shortcut for “step into”.

Shortcuts

These are the main shortcuts I’ve added. Some are inspired by the use of Vim (J moves the cursor to the next line in Vim – her it steps to the next line of code), while others are based on mnemonics (G for “Go” to either start or continue debugging, S for “Stop“), etc.

Continue reading →

VS Reference Blues

Posted on by kjartan

When code builds but looks invalid, and intellisense is dead

I recently encountered what I at first thought was a bug in Visual Studio, but which turned out to be a poorly described configuration error on my part.

The problem manifests itself like this:

Apparent reference errors
It looks like references are missing, and intellisense is broken, but the code still builds and runs correctly.
Continue reading →

How to disable the visual debug toolbar for XAML in Visual Studio

Posted on by kjartan

I’ve had the pleasure of working with XAML lately. When running a XAML application from Visual Studio in debug mode, this nifty little toolbar is placed on top of windows:

While I have no doubt this can be useful, I often find it annoying too, so here’s how to remove it:

Open Tools and Options from the menu, and search for “Visual” in the top left corner. Remove the tick from the highlighted checkbox, and hey-presto, no more unwanted elements in your UI!

Resharper templates for unit testing with NUnit

Posted on by kjartan

If you’ve ever done test driven development for (TDD) over an extended period of time, you’ll probably agree that writing the same boilerplate test-code over and over can be a hassle. I’m talking specifically about structures like the following:

[TestMethod]
public void SetUp(){ ... }

[TestMethod]
public void Should_Do_Something_Or_Other(){ ... }

[TestCase("input")]
public void Should_Get_Some_Info(string targetPerson){ ... }

 

Writing a large number of tests quickly is perhaps the primary defining characteristic of a TDD process, so being able to generate code like the above quickly is an obvious advantage. If you use Resharper, you can add your own code templates to help you achieve this.

Below you’ll find three templates that I’ve been using for some time now, along with a description of how you can set them up in Visual Studio in under a minute.

Resharper Live Template Editor

Resharper Live Template Editor

Continue reading →

“Operation could destabilize the runtime” caused by dynamic invoke.

Posted on by kjartan

Dynamically invoking code can sometimes mask errors that actually are pretty simple to fix. If you come across problems like this, it’s probably a good idea to try to reproduce the problem as close to the calling code as possible, in order to see the actual error message, instead of something generic like the title of this post.

Continue reading →