Skip to content

Debugging xUnit Tests Using MonoDevelop


After several months of neglect, we are currently working on getting the Nancy project ship shape on Mono. We’ve gotten to the point now where everything builds and runs just fine, but we have a few tests that fail when running on Linux/Mono. The failures we are seeing are obviously bugs in the tests/stubs/mocks themselves, and we need to debug them to see exactly what’s going on. MonoDevelop has some decent test runner features, but they appear to be heavily tied to NUnit which is a problem if you happen to use xUnit 🙂

Debugging With xUnit

Luckily the solution is relatively simple, if a little clunky:

  1. Download the latest xUnit release and unzip it somewhere.
  2. Set whatever breakpoint you need in MonoDevelop and build the test project (in debug mode, obviously).
  3. In MonoDevelop, go to Run, Debug Application, browse to where you extracted the ZIP from step 1 and choose the appropriate xunit.gui.*.exe depending on your target framework/architecture (xunit.gui.clr4.exe in our case).
  4. The gui xUnit runner will popup – click Assembly, Open, browse to the output of your test project, select the assembly and press OK.
  5. Click Run All in the bottom left.

The runner will run the tests and you should break out into MonoDevelop whenever you hit a breakpoint.

Pretty simple, if a bit of a ballache – but hey, you shouldn’t need to debug your tests very often anyway 🙂

Posted in .Net, CSharp, Nancy, Software, Uncategorized.

Tagged with , , , , , .

Switching from Cygwin to MSysGit – Git Thinks Everything Has Been Modified :-(


I’ve been dabbling with git lately, contributing to the Nancy project, and I’ve been happily working away using Cygwin, which I already had installed, and all was fine and dandy. Things went slightly awry, however, when I decided to give MSysGit a whirl. Typing “git status” on my (unmodified) repository, that I’d previously used with Cygwin, showed every single file as modified.. argh!

Faking FileModes

A quick “git diff” showed this output for every file:

old mode 100755
new mode 100644

A brief Google later and it turns out that MSysGit “fakes” filemodes (unix permissions – the 755/644 part of the log above), whereas Cygwin, which is a more “complete” Linux implementation on Windows, does them “properly”. Now, by default, git tracks the filemode and considers it a change whenever it’s modified, so the “fake” modes coming back from MSysGit were making everything appear modified.


Luckily, the solution is very simple – tell git to stop tracking filemodes! I set this as a global option, but also had to set it on the repository too as it has a default value set in there. The following two commands sorted it out:

git config --global core.filemode false
git config core.filemode false


A simple fix to a, potentially, obscure problem; but I think if you’re using msysgit to work on non-Windows projects, that may have filemodes set for executable scripts, then this workaround may be required too. Apparently MSysGit does attempt to fake the filemode based on file extension, so things that *look* like they should be executable are faked to have +x, but it’s not going to be perfect.

Posted in Misc, Rambling.

Tagged with , , .

Quick Add Reference Extension for Visual Studio 2010


I mentioned this on Twitter last week, but completely failed to find it again today, so thought it was worth blogging for future reference Smile 

As I have blogged about in the past, the Add Reference dialog in Visual Studio is still pretty terrible in VS2010. Various extensions have made it more bearable by providing search support and other enhancements, but now you can avoid it completely (most of the time) with an excellent extension from Clarius Consulting:

Anyone that’s used ReSharper will instantly recognise the approach – just hit Ctrl+. for the VS2010 Smart Tag on something you don’t currently have referenced, and voila – an option to automatically add the reference and the corresponding using statement:


Simple and effective – I haven’t had any problems with it since I installed it last week – go and give it a whirl Smile

Posted in .Net, Misc, Software.

Tagged with , , , .

Silverlight Masterclass – Discounts for NxtGenUG Members


Shawn Wildermuth’s “Silverlight Tour” is coming to the UK, in the guise of the Silverlight Masterclass, and NxtGenUG members can receive £50 off the course price (in addition to the current “early bird” offer if you qualify for that).

The 3 day developer course looks quite comprehensive, starting with Silverlight, XAML and Blend basics on day one, working with data on day two, and finishing off with more advanced topics like MVVM, MEF and PRISM on day three. It’s great to see some patterns and practices coverage in a Silverlight course, especially given my recent experience trying to recruit Silverlight developers!

In addition to the discounts you can also win a free ticket to one of the courses by blogging about it yourself using the text from the “pitch” below. For more details on the competition take a look at Ian Blackburn’s blog entry.

The Pitch

The Silverlight Tour comes to the UK – and it’s called the Masterclass!

This 3 day hands-on training with both designer and developer tracks looks awesome and (uniquely) has two expert trainers per course.

Currently scheduled in London, Manchester, and the Midlands for June, all courses also come with the chance to win an xbox 360, and Silverlight Spy licences!

Early bird discount of £100 if you book in May, and if you are a member of #SLUGUK or #nxtgenug there are additional discounts to be had.

Full Details are here:

In addition bbits are holding a raffle for a free ticket for the masterclass. To be eligible to win the ticket (worth £1095!) you MUST paste this text, including all links, into your blog and email with the url to the blog entry.  The draw will be made on June 1st and the winner informed by email and on

Posted in .Net, Silverlight.

Tagged with , , , , , .

Optional Parameters in C#4, C#3 and VB.Net, With a Side Order of IL Quirks


One of the features C# has gained in it’s latest V4 incarnation is the ability to work with optional parameters. Now VB.Net (and the underlying IL) has had this ability for sometime, but as it’s new to C# folks, and causing a little confusion; I’m going to attempt to explain how it works, when it works and the potential gotchas. I’ll also cover a strange inconsistency between the the VB and C# compilers when it comes to named parameters.

Warning: This post contains IL, but don’t let that put you off – you don’t actually need to understand it to get the point of the post!

So It’s C#4 Only, Right?

Sort of 🙂 Just to confuse things, optional parameters, from both a definition and consumption perspective, are really the concern of the compiler. As other posts have correctly pointed out, as long as you’re using Visual Studio 2010 you can define and consume optional parameters while targeting an older framework version:

public void DoThings(int intParameter = 22, string stringParameter = "Default")
    // Do things

// ...

DoThings(); // Uses the default values

This will work whether you’re in the same assembly, or consuming a library that already exposes methods with optional parameters.

You can also happily consume C# libraries containing optional parameters with VB.Net; even if the VB.Net project is still running under VS2008. The reason this works it that the IL that the new C# compiler is emitting is nothing new, and VB.Net has been able to define and consume optional parameters for some time. You can see the IL that is generated for the above method in the ILDASM output below (interesting parts highlighted in yellow):


The one thing you *cannot* do is consume optional parameters using C# in Visual Studio 2008; even if you’ve built the library in VS2010 and targeted the older framework. The C#3 compiler just doesn’t understand (or more to the point doesn’t care about) optional parameters. If you try and build the code above using Visual Studio 2008 you will get the following error:


Definitely something for library authors to consider – we’re not quite out of “overload hell” yet unfortunately.


Now you may well think that when you consume an optional parameter, the compiler is emitting code that pulls the default value from the method information at runtime – but that isn’t the case. In a similar fashion to the way the compiler handles consuming consts, the default values are “baked into” the calling code. This is true whether the calling code is in the same assembly as the definition, or a separate assembly . The following ILDASM screenshot shows the IL generated for the DoThings() call above (interesting parts highlighted in yellow again):


Even if you don’t fully understand the IL you can clearly see the constant values in the code are “baked into” the TestStuff() method.

The issue this can cause is the same for exposing public consts – if you change the default values in a library, but don’t recompile the calling code, then the calling code will still call your method(s) with the old default values. This is definitely something you need to consider when designing APIs using optional parameters.

One potential way to “work around” this issue and avoid “locking yourself in” to a particular set of defaults would be to follow the following pattern:

public void DoThings(int? intParameter = null, string stringParameter = null)
    if (intParameter == null)
        intParameter = 22;

    if (stringParameter == null)
        stringParameter = "Default";

    // Do Stuff

In the code above we still get the benefits of having optional parameters; but because we use “marker” values for defaults (nulls in this case), and set the *real* defaults inside the method, we are free to change the real defaults at a later date. This technique does require more code, and doesn’t look quite as elegant as the previous example, but in my opinion the benefits outweigh the drawbacks, especially for public APIs.

A VB/C# Named Parameters Quirk

As I was pulling together the IL for this post I discovered a small “quirk” when comparing the IL output by the VB.Net compiler to the output of the C’# compiler when dealing with named parameters. If we call the DoThings() method above and specify just the stringParameter the IL produced by the VB.Net compiler looks as I would expect:


The default value for the intParameter is pushed onto the stack, followed by our “Nondefault” string value and the method is called. The IL produced by the C# compiler is slightly different though, as shown by the highlighted sections below:


In the C# version the “Nondefault” string is pushed onto the stack *first*, then pops it off into a local variable (stloc.3), the default value for intParameter is then pushed, followed by the contents of the local variable (ldloc.3).

Not a massive difference, and I’m sure there’s a good reason for it, but the C# version does look decidedly “odd” to me. I’m no expert in IL performance, but this may be conclusive proof that VB is faster than C# 😉 *

Update: Marc Gravell was kind enough to review this post for me and correctly pointed out that I should really be comparing IL for *optimised* builds, not debug builds (which have optimisation turned off). Marc has done this for himself and confirmed the stloc and ldloc are still present, so my point is still valid (*phew*)

* Note: This is a joke.. I got some abuse on Twitter for “VB bashing” recently, hopefully this will appease the VB heads! 🙂

Posted in .Net, CSharp.

Tagged with , , , , , , , , , .