Honestly, I’m not affiliated with JetBrains in any way, but I think they’ve got a fantastic tool, which makes a developers life a whole lot easier. If you are a C# developer, you should check it out.

I’m still discovering new functionality, even after using it for a few years. In this post I wanted to share my favorite shortcuts. They’ve saved me countless hours, so hopefully you’ll find some new ones, and save yourself some time too!

A remarks before we begin: these are the default ReSharper mappings, but it’s possible that you’ve made some changes to these mappings. If they don’t work, head over to your Visual Studio settings and check your keyboard mappings

Here they are (in no particular order)

Alt-PageUp/Alt-PageDown and Alt-Enter – Next/Previous highlight and Quickfix
It gives you a great feeling of power and control, just cruising over all the warnings in a file with Alt-PageUp/PageDown and fixing them with Alt-Enter. Clean code in no time.

Shift-Alt-L – Locate in Solution Explorer
When you need to quickly locate the file you have open in the Solution Explorer, this handy shortcut does the trick. You’ll be amazed at how many times you can use this!

Ctrl-F12 – Go to Implementation
Navigating around my code with F12 (Go to Definition) was common practice, but on an interface most of the time I wanted to go to its implementation. You can imagine my joy when I discovered this shortcut 🙂

Ctrl-Shift-R – Refactor this
The mother of all refactoring shortcuts. This gives you a context menu with the possible refactorings in the current context.

Over the years our team has been working according to Agile pratices and we’ve slowly grown into them. The process took alot of effort on our part, to keep pushing us forward and keep learning from our mistakes. Having made these mistakes, we where more keen on implementing the practices and we can still reference back to them now when something starts to slide the wrong way.

An interesting article was published on Martin Fowlers site called Your Path through Agile Fluency. It hits quite a key point in the fact that Agile (and Scrum, XP, …) practices are easy to teach and understand in a classroom, but difficult to implement in real projects. They don’t provide a ‘silver bullet’ methodology which changes efficiency from one day to the next. Teams take years to progress trough the Agile Fluency path, and most of them never get beyond level 1.

In our team, I think we now have a solid base in level 1 and our slowly working our way to level 2. Will we ever get to 3, or even 4? Is it even necessary for our team? Time will tell…

Are you working on an Agile team too? Have the same experience? What level do you think your team is on?

Recently a friend of mine handed me a copy of Martin Fowlers Refactoring: Improving the Design of Existing Code (that’s what friends are for). The book is considered a standard on refactoring en can still be seen as a must-read for every programmer, although it published in 1999.

Refactoring means to rewrite code, in small, safe (backed by unittests) steps. Doing this cautiously ensures that there is no loss of functionality and results in a decrease of error-proneness of the code and an increase in readability and maintainability. As Folwer mentions: the compiler reads your code once, while your and your colleagues will be gazing over it and changing it a lot times during coding. Making sure your code is readable (really readable, like a book) will save you and your coworkers a lot of time!

Fowlers book also helps you maintain the DRY (Don’t Repeat Yourself) principle. If you have to duplicate a piece of business logic in your code, it WILL cause you trouble. When the logic has to be altered, you can be sure that one of these places will be forgotten.

Before Fowler starts working on a piece of code, to fix a bug or add new functionality, he’ll often start with a refactoring to better understand the code. This may sound strange, but it is almost impossible to write perfect code from the start. I don’t mean working code, but code that is open enough to support all the possible questions, extensions or other changes and still is small enough to only do what it needs to do. If you accept the fact that you are going to have to refactor, and that it’s not a failure for you as a programmer, you can write better, cleaner code.

My favorite tool to do this (in .Net) is the fantastic ReSharper. A lot of the refactorings in the book can be done automatically and safely with this tool. It has an enormous list of functionalities, and I’m still discovering new uses every day.

An important note on refactoring is knowing when to stop. Knowing when to start is one thing, but at least as importing is knowing when you’ve refactored enough, or when a refactoring isn’t going as planned and the best thing to do is undo your changes. Huge reworks are done one refactoring at a time. You can always come back tomorrow to do the rest of them. As long as you leave the code in a better state than it was before, your good!

Refactoring fits perfectly in the iterative Agile process and is a corner-stone of Extreme Programming (XP). It’s no coincidence that Martin Fowlers can be found underneath the Agile Manifesto. Clean code will also provide value for the customer. Although it sounds counter intuitive, investing time in refactoring saves time writing code. A win-win!

I’m had to do some biztalk 2009 development on my machine, but it already had visual studio 2010 installed. So I had to install VS2008, which went better than I hoped (did not have to do an uninstall of 2010).

So I had my biztalk 2009 and my Visual Studio 2008 installed and was ready to go when I came across a problem. When I tried to open an existing or create a new Biztalk project I got this error:

Creating project ‘BizTalk project name’… project creation failed.

Damn…

After some google-fu I found a lot of people experiencing the same problem and even an msdn page about my problem. All of the evidence was correct. I had installed VS2008 SP1 after I installed biztalk.

From the MSDN page:

When Visual Studio 2008 is repaired or when a Visual Studio 2008 update is installed, the value of the following registry entry is changed from csproj;btproj to csproj:

The problem was that I did not have a PossibleProjectExtensions registry key. I added it, with the correct values. Same error. I repared biztalk. Same error. I restarted multiple times. Same error.

I tried to set the registry key to the value it should have been after an update of Visual Studio (only ‘csproj’) and after doing a repare of Biztalk then I found it changed the value to the correct value. Still, the same error…

So I gave up for now, lost too much time on it already. I’m developing biztalk on a different (virtual machine). Still if anyone has found a solution or experienced the same problem let me know, maybe we could start a self help group…

In our line of work it can be vital to keep up with the latest technology. Blog are ideal to keep up with recent news.

My favorite programming related blog is definitely that of Scott Hanselman. The humor he brings to these technical subjects is always entertaining. Also, he is one of my favorite speakers!

Another great blog to keep up with .Net related news is that of Scott Guthrie. Great in depth technical information.

Finally the ideal blog for programmers who don’t have enough time to keep up with all the blogs out there: The morning brew. Having someone wrap up all the interesting other blog posts daily means I don’t have to and can just read this one post!

A while ago I was having trouble while debugging in Visual Studio 2010. Each time my debugger had to load symbols to the dll’s I used it went really slow, sometimes even took minutes (or felt like minutes) before I could start debugging. This could not do on my all powerful development machine!

To google!

As with most of life’s problems (or at least most of life’s programming related problems) an answer could be found on stack overflow.
It turned out my experiments with WinDbg where at the root of the problem. In order to get it to load symbols I added some environment variables (‘_NT_SYMBOL_PATH‘ and ‘_NT_ALT_SYMBOL_PATH‘).

Now, Visual Studio has a nice settings screen dedicated to symbol loading, but if you have these environment variables set on your system, it just ignores them. Good stuff…

So after removing both these settings I could debug as fast as lightning again!

I haven’t needed WinDbg since then, so maybe I’ll run into trouble again if i need to use that again. But instead of using WinDbg i’ve used the sos.dll (which I used to debug memory leaks) from inside of Visual Studio, which worked out nicely…