As I’ve promised, I will start documenting my experience with Aurelia. If you haven’t read my previous introduction article, click here to get an insight of what Aurelia is.

Since I’m writing this post during Sunday night, I will keep it short and just talk about tooling.

I am not the hacker-notepad-vim kind of guy and the first thing that I need when I work with any technology/framework is a good IDE. I’m a veteran user of Visual Studio + Resharper, so obviously my first choice when starting with Aurelia was to use this.

Unfortunately, VS 2013 + Resharper does not currently have any support for ES6 so it kind of stands in your way. Of course you can still use it as a text editor, but it’s even worse than using any notepad alternative since it always highlights the whole code as having errors and the formatting just messes things up (misaligned curly brackets or parenthesis, wrong spacing etc.).

After searching a bit on the internet and almost loosing all hope to have a nice IDE for this, I found out that JetBrains Webstorm IDE actually has support for ES6, so I will be using this from now on for my experiments.

Just as a hint, if you want to set Webstorm up, check out this short video on how to use Webstorm + Traceur. The default Aurelia template already transpiles ES6 to Javascript, but if you want a more integrated experience, you can configure the IDE to do it for you:

A lot of people involved in web development (including myself) have hit a problem with the latest versions of jQuery. Right now there are two versions of jQuery available on NuGet – 1.9.1 and 2.0.x. According to the jQuery team, both versions will be developed in the future and for developers targeting web applications the recommended version is 1.9.1 instead of 2.0 (jQuery UI for example does not work with v2.0).

By default NuGet will install the latest version of jQuery automatically. Of course, if you use the Package Manager Console, you can force version 1.9.1. But as soon as you update and you forget to do a safe update (see my previous post here on how to do that), you are stuck with version 2.0.

To prevent such issues, an easy solution is to force the package to stay under version 2.0 by changing it in the packages.config file like this:

This is a follow-up on my previous post with a slight variation of the command. If your package source contains pre-release packages, then the previous command is not enough. The change is minor, though:

there are situations when you need to update the referenced NuGet packages and use a safe update.Safe update means that the packages are updated to the latest version that has the same major version as the current one. For example: suppose the project has a reference to “MyPackage” version 1.2.3.4. In the NuGet repository there is a MyPackage version 1.2.7.8 and one with version 2.0.0.0.

A safe update would update the package to the version 1.2.7.8, while a regular update would update it to the latest version (2.0.0.0). While the safe update can be done using the package manager UI from Visual Studio, the safe update requires using the powershell console directly.

Fortunately, there is a very easy way of updating safely all references. Open the Package Manager Console (Tools->Library Packager->Package Manager Console) and type the following command:

How many times you had to build a console application that must receive various input arguments? I know I did a lot of times – from small development tools to various applications. And every time there was a big PITA to handle the input arguments. Every time I have reinvented the wheel, every time I had to check for the arguments, parse them, output various help messages etc.

As a WPF developer, I often find myself trying to debug the visual structure of my applications or to find out why something doesn’t work as expected. The Visual Studio debugger can help up to a certain point, but for runtime visual debugging it lacks the necessary features. Luckily, there is an awesome free tool that you can use for this – Snoop. The tool itself is very straightforward – you select your running application press a button and you can see the whole visual tree:

I find that with the extension support in VS2010, programmers don’t really have an excuse for not using tools to increase their productivity and to increase the overall quality of their work. I am a really lazy programmer, in the sense that I don’t’ like to do repetitive boring tasks. Extensions are one of the solutions to being a happy lazy programmer. The other one is writing quality code, but that’s another story. So here is a list of all Extensions that I use in day-to-day work

When doing TDD or at least unit testing, it is necessary to know how much of your code is covered by tests and, more importantly, which code isn’t. Since we migrated to NUnit the integrated Visual Studio 2010 code coverage does not do the job anymore for us (although I’ve found several articles on how to enable it, for some reason I couldn’t get it running).

There are two tools that you can use instead – one of them is NCover, which is a great tool but not free. The other one is PartCover, which is a free code coverage tool. I’ve opted to go with the latter. The main problem with PartCover is the almost non-existent documentation. After several hours of trying out different combinations of options I finally got it running and it does it job really good.

One of our main requirements when performing the migration was to have the same level of integration with our Team Build system. This means that the build should run all tests and fail if any test fails. Also we should be able to see in the build log which tests have failed.

This step is the most complicated one so here is a quick breakdown of all the steps involved: