What is it?

NuGet is Microsoft’s answer to the much-lamented gap in the .Net space for a package management tool like Ruby’s Gems or Linux’s RPM.

NuGet simply looks after the download and installation of tools and libraries you use in your projects.  It will get the appropriate version of all needed DLLs, configuration files, and related tools, put them in a folder, and do any configuration if needed.  Simple!  Also useful is the fact that it will download any dependencies – so for example if we want to install Shouldly, which uses Rhino Mocks, NuGet will get the appropriate version of that as well.

And that’s about it.  So it won’t change your world, but it will save you a good few hours each year hunting for, downloading, and installing tools.

History

NuGet started out as NuPack, which kind of took over from the Nu open source project.  Indeed, NuGet is itself open source, continuing Microsoft’s trend of a more transparent and community-involving future, which is nice.

There are other package managers for .Net, including:

• OpenWrap
• Horn
• Bricks
• NGems

However, as usual, things don’t tend to take off in the .Net community until Microsoft makes their version, which then becomes king. I haven’t tried any of those package managers, but I wouldn’t want to bet on them being too successful now NuGet’s out.

Anyway, enough of the history lesson, how do I use this thing?!

Installation

Firstly, you need to get it installed, which is simple as it’s in the Visual Studio Extension Manager (Tools -> Extension Manager).  Search the Online Gallery for ‘NuGet’ and you should find it:

VS2010 Extension Manager

A couple of clicks later and you’re ready to go!

Putting it to Use

There are two interfaces.  You can either right-click on a project and select ‘Add Library Reference’, and find what you need with a handy visual interface (the same as the Extension Manager):

NuGet Visual Interface

Or, by selecting Tools -> Library Package Manager -> Package Manager Console,  you can use the Powershell-based console version, like a real developer!

NuGet Console

(Check out some NuGet Console Commands, if that’s how you want to roll.)

Either way, you’ll end up with a new ‘packages’ folder in your solution, containing the bits you need (as well as having references automatically added to your project, and configuration set):

Packages Folder

Et voilá!  You’re ready to log/unit test/mock/whatever to your heart’s content.

You can also delete packages, update packages, and so on – it’s all pretty straightforward, so I’ll leave you to work that out.

So what are you waiting for?  Go and nu-get it now!!  (sorry..)

describe User do
  it "should be in any roles assigned to it" do
    user = User.new
    user.assign_role("assigned role")
    user.should be_in_role("assigned role")
  end
it "should NOT be in any roles not assigned to it" do
    user.should_not be_in_role("unassigned role")
  end
end

Aside from the test name being a string, you can see the actual assertions in the format ‘variable.should be_some_value’, which is kind of more readable than it might be in C#:

Assert.Contains(user, unassignedRoles);

or

Assert.That(unassignedRoles.Contains(user));

Admittedly, the second example is nicer to read – the trouble with that is that you’re checking a true/false result, so the feedback you get from NUnit isn’t great:

Test ‘Access_Tests.TestAddUser’ failed:  Expected: True  But was:  False

Fortunately, there are a few tools coming out for .net now which address this situation in a bit more of a ruby-like way.  The one I’ve been using recently is Shouldly, an open source project on GitHub.

Using Shouldly (which is basically just a wrapper around NUnit and Rhino Mocks), you can go wild with should-style assertions:

age.ShouldBe(3);

family.ShouldContain(“mum”);

greetingMessage.ShouldStartWith(“Sup y’all”);

And so on.  Not bad, not bad, not sure if it’s worth learning another API for though.  However, the real beauty of Shouldly is what you get when an assertion fails.  Instead of an NUnit-style

Expected: 3

But was:  2

- which gives you a clue, but isn’t terribly helpful – you get:

age

should be    3

but was    2

See that small but important difference?  The variable name is there in the failure message, which makes working out what went wrong a fair bit easier – particularly when a test fails that you haven’t seen for a while.

Even more useful is what you get with checking calls in Rhino Mocks.  Instead of calling

fileMover.AssertWasCalled(fm => fm.MoveFile(“test.txt”, “processed\\test.txt”));

and getting a rather ugly and unhelpful

Rhino.Mocks.Exceptions.ExpectationViolationException : IFileMover.MoveFile(“test.txt”, “processed\test.txt”); Expected #1, Actual #0.

With Shouldly, you call

fileMover.ShouldHaveBeenCalled(fm => fm.MoveFile(“test.txt”, “processed\\test.txt”));

and end up with

*Expecting*

MoveFile(“test.txt”, “processed\test.txt”)

*Recorded*

0: MoveFile(“test1.txt”, “unprocessed\test1.txt”)

1: MoveFile(“test2.txt”, “unprocessed\test2.txt”)

As you can see, it’s not only much more obvious what’s happening, but you actually get a list of all of the calls that were made on the mock object, including parameters!  That’s about half my unit test debugging gone right there.  Sweet!

Shouldly isn’t a 1.0 yet, and still has some missing functionality, but I’d already find it hard to work without it.  And it’s open source, so get yourself on GitHub, fork a branch, and see if you can make my life even easier!

As such, I was most pleased to hear about MagCloud, an online service which offers printed magazines in a FUBU (For Us By Us) style.  Basically, anyone can upload a magazine in PDF format, and for a charge of around $0.20 a page, MagCloud will print it out and send it to you.  This works out at around £5-6 for a magazine of 40 pages, which is a little expensive but not too bad.  (There’s a delivery charge of $2-3 too, so you’re better off getting a couple at a time).  While the authors can make money from this (by adding on an extra charge per page), none of the ones I was looking at did so.

The two I checked out are well written and informative:

Hacker Monthly

Hacker Monthly, a general programming magazine, and

Rails Magazine

Rails Magazine, about Ruby/Rails.  I couldn’t find any specific .Net ones when I looked, but it’s pretty new so I’m sure one will appear at some point.  So if anyone fancies starting a .Net mag, here’s your chance!

Now, many of these are available as PDFs for you to download as well, so you could quite easily print them off yourself and save a few quid.  Personally, I’m too lazy/disorganised for that, and I like to have a proper magazine and not a scruffy collection of stapled sheets, but that’s just me.

Check it out.  What have you got to lose?!

Before you read any further, if you’re looking for an example of a decent WPF UI, stop now!  I can assure you, you’ll only be disappointed..  I used a theme so it wasn’t grey, but that’s about it.  It’s all about the code!

The Code

The source code is here: http://code.google.com/p/wpf-diet-recorder/

If you have a SubVersion client such as TortoiseSVN, you can download the latest Source, otherwise you can go to Downloads and get a handy Zip file with it in.  You’ll need Visual Studio 2008 and above to use this (I haven’t tried it with 2010, but it should work Ok).

I’ve marked this example as version 1.0.0.0 – I may or may not continue doing anything with it afterwards.  (Although I’ll undoubtedly find an issue with it and have to put a version 1.0.0.1 out shortly..)

The App

The app lets you record your weight and some notes on the Measurements screen:

This can be done for multiple users, which are set up on the Users screen:

(You might notice the Users screen allows you to define custom measurements for the users – these aren’t used anywhere at the moment, as putting that in was making it too complex for this example).

Features

A couple of interesting things in there are:

• Automated Unit Testing (of course!)
• Composite views (the ‘custom measurements’ part of the Users screen is a separate user control with its own ViewModel)
• No code-behind
• Commands using DelegateCommand
• ValueConverters

Unit Testing

Although there aren’t as many unit tests as I would like, there should be at least examples of the main things you’d want to test.  (My only excuse for the lack of tests is this was my first WPF app, and as such basically a prototype, so I was working it out as I went along).

I’ve used Roy Osherove’s naming convention for the unit tests (MethodName_StateUnderTest_ExpectedBehaviour), as I like it.  I’ve also stuck with the AAA pattern for the test layout (Arrange, Act, Assert), and when I’ve used Rhino Mocks for test isolation, that’s been in ‘AAA mode’.

ValueConverters

There is still much discussion in MVVM circles about whether ValueConverters should be used, or if the ViewModel in MVVM should render them unnecessary.  I’ve used ValueConverters as I don’t want to have too View-specific things (such as Visibilities and Colours) in my ViewModel, but some people (including Josh Smith, the father of MVVM) disagree.  To be honest, it doesn’t matter much (especially if you’re just starting out), but it’s good to be aware of your options.

Validation

Always tricky to know where to put the validation – in this case, I’ve gone for validating the data type in the ViewModel, and any more complex validation (string lengths, max and min value, etc) in the model itself.

Libraries / Tools

The things I’ve used to build this (aside from VS2008) are:

• NUnit for unit testing
• RhinoMocks for isolation (mocking)
• Versant DB4O for the data store (it’s an Object Database, so don’t go looking for the SQL!)
• WPF Toolkit for the theme
• WPFMessageBox for the message box

Further Development

If I was to continue developing this example, there are a couple of things I’d probably want to do:

• Make some kind of Application Controller, which would contain the ugly startup code from App.xaml.cs and be in charge of opening forms
• Use an IoC container such an Ninject to resolve those dependencies
• Probably take the data loading/saving logic out of the ViewModels and find somewhere more appropriate for it

That’s It!

Hopefully someone might find that useful.  If you have any questions, feel free to get in touch.

Anyway, TekPub isn’t free, a year’s subscription costs $200 (or you can pay on a per video or monthly basis), but there are several free videos on there which are well worth watching.  (I luckily won a year’s free subscription at a NxtGenUG user group meeting, which is what took me there in the first place).

There are two free series of videos, which are both useful. One is based on Mike Gunderloy’s book ‘Coder to Developer’ and basically discussed how to move from a cowboy to a professional developer, making proper use of things like source control and project organisation tools.  Not much new for a seasoned developer, but useful for many currently making the journey.

The other free series is called ‘Concepts‘, which (using C#) covers a lot of the things a growing developer needs to learn – IOC Containers, Unit Testing, Interfaces, and even Behaviour Driven Design (BDD).

And if you’re willing to fork out, there are tens if not hundreds of hours of content on subjects from ASP.Net MVC to iPhone development, jQuery, Git, Ruby, and many more.

So instead of turning on the TV tonight, get over to TekPub and learn something useful instead!

Anyone who’s been working with WPF for any length of time will probably already know about this, but for anyone else, one of the tools you have to check out is Snoop, originally posted by Pete Blois and now hosted on CodePlex.

Snoop is basically a debugging aid which allows you to see exactly what’s happening in your running WPF app.  This can be very handy, as XAML can get a bit confusing after more than a couple of buttons, and there are also problems like binding errors (when you miss-spell a property name in your XAML) not making themselves apparent.

Snoop runs against your running application, so if you do anything fancy with dynamic control generation, it will be included.  One of the more useful aspects is the ability to see everything in the visual tree:

Snoop showing the visual tree of my WPF app

Aside from all of the properties of the selected control being shown, you might also notice the selected UserGrid being displayed, which is handy – Snoop also cleverly highlights the selected visual component on your running app:

Snoop highlighting the selected control

You can also use this to show any controls which have binding errors (a common issue in WFP if ur spellin is bad like wat mine is):

Binding Errors highlighted in Snoop

As well as those genuinely useful features, there are a couple of really cool things which are good for showing off – the first is the ability to magnify your app (so you can prove WPF really is using vector graphics!):

Zooming with Snoop

Check out them corners.. Sweet!

And last but not least, watch in amazement as Snoop explodes your app into a magnificent 3D masterpiece!

Mum, my app exploded!

And that’s not just a static image either, you can spin it around and all sorts.  Now come on, who’s not going to be impressed by that?!

So, to summarise, Snoop for WPF – if you haven’t got it, go get it now!

One of the worst offenders for this is the Command model, whereby in your ViewModel you define a class which implements ICommand.  This is made available to the View via a property, and when called, calls some method in your ViewModel.

(Note:  This only applies to WPF.  Silverlight doesn’t currently support commands in the same way.)

Here’s an example, from inside my ViewModel (MeasurementViewModel):

(This is set up in the XAML as follows:)

You can see the custom ICommand (AddDefinitionCommand), a local variable to hold it, and a property getter for the view to find it.  Now considering that this doesn’t even have the code which performs the action (which is viewModel.AddMeasurementDefinition), that’s lot of overhead.  And you have to do that for every single command!  That’s button clicks, selection changes, and so on.

One of the problems is that the Command model provides a lot of flexibility by defining the CanExecute() method and CanExecuteChanged event, but I don’t need those in my simple scenario.

So, how to write a bit less code?  Of course, you could make some good use of Code Snippets, but there are better solutions.  The best one I’ve found is the DelegateCommand approach used in Microsoft’s Composite Application Library (a.k.a Prism), also discussed in Josh Smith’s MVVM article (where he calls it a RelayCommand).  This involves defining an ICommand which uses delegates, and means you have less boilerplate code to write.

As I’m not interested in using the full features of the ICommand, my simple DelegateCommand goes like this:

DelegateCommand.cs

And to call it, you simply need the following:

You can see the local member for the DelegateCommand, the ViewModel constructor where we define the method to call, and the property to make it available to the View.  Much simpler, I’m sure you’ll agree!

Of course, if you want to include the rest of the Command functionality, you can just extend the DelegateCommand.  So there you have it, all of your MVVM problems solved!  Well, nearly..

The Code

(As I don’t seem to be able to upload DelegateCommand.cs for you to download, here’s the text for you to copy & paste.  I’ll work WordPress out one of these days…)

WCF Usage Diagram

Service

This is your actual service, which is just made up of standard .Net code, usually an interface and the implementation.  The interface has a couple of attributes on it to make itself known to WCF as a service, e.g.:

In VS2008, you can create this by adding a new ‘WCF Service Library’ project, which includes some example code.

Host

The host is whatever runs the service, making it available on a particular address.  In most cases this will be IIS, but it could be a Windows Service or even just a console/winforms app.

Either way, you’ll need some config to specify the Address, Binding and Contracts (known as the ABC), which in it’s most basic form will look something like this:

These are collectively known as an ‘endpoint’.  If you created a WCF Service Library for your service, Visual Studio will actually have created this for you in an App.config file, which you can just copy into your host application.

Then to run the service, just stick this in your main():

Client

Here’s where you actually call your service, again just a standard application of your choosing.  The point at which it turns into a WCF client is when you select ‘Add Service Reference’ in Visual Studio, and give it the address of your running service.  This does a load of magic, and the important things you and up with are:

• A config file with the relevant WCF endpoint in it
• A service proxy

The proxy is basically a local version of the service that you created.  If you look at all the files in the service reference, you will see ‘reference.cs’, which contains your service methods.  When we want to call the service from the client, we just make a call to this proxy, which goes away and handles all of the tricky networking stuff in the background so you don’t have to worry about it.

How simple is it?  Here’s the code:

Conclusion

So, WCF’s pretty easy to use.  The main issue you’ll face are probably with config, and firewalls (addresses not matching, remote machines not responding, and so on).  Once you get into it, WCF’s a massive technology, but at a basic level it’s pretty straightforward.

Apologies if this was a little short, but I thought it was about time to feed the blog!  Feel free to get in touch for more details.

Anyway, audio tips and sexism aside, here are all of the podcasts I’ve been listening to and what I think of them, in order of greatness:

Herding Code

Rating: 10/10

Technology: Mainly .Net

Sound Quality: Average

Hosted by four smart and fairly amusing guys, the beauty of this podcast is that you always get to hear all sides of the argument on any given topic.  And unlike some of the other podcasts, the topics are nearly always interesting – I rarely skip an episode.  They get some top guests too.

.Net Rocks!

Rating: 9/10

Technology: .Net

Sound Quality: Excellent

Probably the best-known and longest-running podcast out there, .Net Rocks is perhaps the most professionally produced show out there – you could easily mistake it for a radio show.  The presenters are funny and knowledgeable, get good guests and always ask pertinent questions (although you don’t get the same level of  discussion as with Herding Code).

ElegantCode Cast

Rating: 8/10

Technology: Mainly .Net

Sound Quality: Poor – Average

Run by some of the ElegantCode bloggers, this podcast is similar to Herding Code in it’s style, usually with multiple presenters leading to interesting discussions.  It seems to have died since David Starr left for the PluralCast (see below), but I’m hoping it might get resurrected.

Alt.Net Podcast

Rating: 7/10

Technology: Mainly .Net

Sound Quality: Average

Although this only lasted a short while, the few podcasts it created covered some really useful subjects, in good detail.  And being Alt.Net (if you’re aware of that movement), there are also some interesting debates and disagreements in there.  Well worth a listen.

Pluralcast

Rating: 7/10

Technology: .Net

Sound Quality: Good

Having recently taking over from the Elegant Code Cast, the Pluralcast has made a good start, covering some interesting subjects.  Although run by a commercial company (PluralSight Training), the shows don’t feel like they’re trying to sell you anything.  The interviews are sometimes a little one-sided, and the shows don’t always flow as well as they might, but definitely one to try out.

HanselMinutes

Rating: 6/10

Technology: .Net

Sound Quality: Excellent

Alongside .Net Rocks, HanselMinutes is the other well-produced, long running podcast.  Scott is currently a Senior Program Manager at Microsoft, which means he gets some great guests and inside scoops, but sometimes the interviews are again a little one-sided.  Scott’s a really smart guy and knowledgeable developer, and I feel bad for only giving a 6, but the subject is often web development (which I’m not really into), and I often skip shows because I’m not that interested in the guest/subject.

Software Engineering Radio

Rating: 6/10

Technology: All

Sound Quality: Good

I’ve really only just started listening to this so it’s a little early to give my opinion – but when did that ever stop a reviewer?!  So, as you might imagine from the title, it covers general software engineering in all languages, often with clever academic people being interviewed by other clever academic people.  Ok, perhaps I undersell it there, it’s not all academic – and it is good to break out of .Net every now and again.

The Thirsty Developer

Rating: 5/10

Technology: .Net

Sound Quality: Average

A show run my a couple of Microsoft evangelists, this has some good content, but the shows are fairly infrequent and I often skip them.  The subjects and interviews can be a little Microsoft-heavy.

The Pragmatic Bookshelf

Rating: 5/10

Technology: All

Sound Quality: Good

Run (although not hosted) by The Pragmatic Programmers, this podcast consists of interviews with the authors of various books on the Prag Pub label.  It’s kind of commercial in that respect, but interesting nonetheless.

Polymorphic Podcast

Rating: 4/10

Technology: .Net

Sound Quality: Good

Again I feel bad about giving this such a low rating, as it’s not a bad podcast, I just don’t like it personally.  I only listened to the first few, but the topics are usually web-based, and were often covered fairly simplistically, and I didn’t really like the presenter.  I think I’ll give it another try soon, as everyone else seems to rate it.

So there you go, plenty to keep you occupied on your lonely commute there!  Obviously those ratings are just my opinion, so don’t take my advice – go and try them for yourself!