Justin a.k.a. The Code Monkey

Code Monkey [kohd muhng'-kee] n : 1. Creature known for it's ability to transform caffeine into code. 2. Justin Jones
posts - 10 , comments - 27 , trackbacks - 0

Saturday, September 15, 2012

Remember way back when we had a free decompiler?

I, like probably so many of the rest of you, was mortified when Reflector was sold to RedGate. I knew where it was going. Suddenly you had to install it instead of just download and run it. I had a deep down feeling that one of the most useful tools in my arsenal was about to become a corporate product and no longer belong to the world of free tools. Sure enough it did. For a while now I’ve limped by without my favorite decompiler. This was made a little easier by the fact that you can now debug into the .net framework, but I still missed Reflector.

JetBrains, makers of the superawesome and well worth the cost ReSharper (no it’s not free) have made their own decompiler that is comparable with Reflector, and it’s free. It’s still a corporate product, and JetBrains isn’t exactly known for making free software, but for now we have an option back on the table until some other industrious developer makes the next Reflector.

dotPeek can be downloaded here.  http://www.jetbrains.com/decompiler/



Posted On Saturday, September 15, 2012 1:59 PM | Comments (2) |

How to write your unit tests to switch between NUnit and MSTest

On my current project I found it useful to use both NUnit and MsTest for unit testing. When using ReSharper for running unit tests, it just simply works better with NUnit, and on large scale projects NUnit tends to run faster. We would have just simply used NUnit for everything, but MSTest gave us a few bonuses out of the box that were hard to pass up. Namely code coverage (without having to shell out thousands of extra dollars for the privilege) and integrated tests into the build process. I’m one of those guys who wants the build to fail if the unit tests don’t pass. If they don’t pass, there’s no point in sending that build on to QA.

So making the build work with MsTest is easiest if you just create a unit test project in your solution. This adds the right references and project type Guids in the project file so that everything just automagically just works. Then (using NuGet of course) you add in NUnit. At the top of your test file, remove the using statements that refer to MsTest and replace it with the following:

using NUnit.Framework;
using TestFixture = Microsoft.VisualStudio.TestTools.UnitTesting.TestClassAttribute;
using Test = Microsoft.VisualStudio.TestTools.UnitTesting.TestMethodAttribute;
using TestFixtureSetUp = Microsoft.VisualStudio.TestTools.UnitTesting.TestInitializeAttribute;
using SetUp = Microsoft.VisualStudio.TestTools.UnitTesting.TestInitializeAttribute;
using Microsoft.VisualStudio.TestTools.UnitTesting;

Basically I’m taking the NUnit naming conventions, and redirecting them to MsTest. You can go the other way, of course. I only chose this direction because I had already written the tests as NUnit tests. NUnit and MsTest provide largely the same functionality with slightly differing class names. There’s few actual differences between then, and I have not run into them on this project so far.

To run the tests as NUnit tests, simply open up the project properties tab and add the compiler directive NUNIT. Remove it, and you’re back in MsTest land.


Posted On Saturday, September 15, 2012 1:17 PM | Comments (3) |

Powered by: