Simple .DistinctBy Extension

LINQ’s Distinct extension has largely been a disappointment to me. Sure, it’s nice when I’m working with a collection of integers, but more often than not, I’m working with a collection of objects and don’t have an IEqualityComparer<TSource> available to me. I know I could just create one, but I just want to use a lambda like just about everything else I do with LINQ!

To the internet!, right? I learned I could use the following trick to accomplish what I want:

  .GroupBy(x => x.key)
  .Select(x => x.First());

Works like a charm, but I got tired of dot-GroupBy-dot-Select-ing and adding a comment about what I was doing for future maintainers, and I think it’s a lot better to just chuck it into an extension method.

public static IEnumerable<TSource> DistinctBy<TSource, TKey>(
    this IEnumerable<TSource> source, 
    Func<TSource, TKey> keySelector
            .Select(grp => grp.First());

Ahh, nice! Alternatively, could score this functionality by adding MoreLINQ to your project. On a neat side-note, you can also cherry-pick which MoreLINQ functionality you want by installing individual packages.


The Way of the Ninject

In recent months, I’ve come to be a big fan of Ninject. I’ve used Microsoft’s Unity Container and Object Builder in the past, but most of what I’d done previously just involved exposing dependencies as properties with lazily-loaded default implementations. I really dig Ninject because it’s so lightweight and easy to use, and it integrates really well with mocking frameworks like Rhino Mocks and Moq.

Getting started with Ninject is really easy and accomplished in just a few steps:

  1. Install the NuGet package
    Install-Package Ninject
  2. Create a module
  3. Create a kernel
  4. Get objects from the kernel

Let’s look at an example. Assume we have the following interfaces and classes.

public interface IFoo {
    void Run();

public class Foo : IFoo {
    private readonly IBar _bar;

    public Foo(IBar bar) {
        _bar = bar;

    public void Run() {

public interface IBar {
    void Print();

public class Bar : IBar {
    public void Print() {

We can create a NinjectModule to create an instance of IFoo like this.

public class FooModule : NinjectModule {
    public override void Load() {

Now, we need to tell our Ninject kernel to use our new module.

IKernel kernel = new StandardKernel(
    new FooModule());

And, finally, we use the kernel to request the objects we need. Note that Ninject does the work of figuring out the default implementation of IFoo (Foo) has a single constructor that accepts a dependency, IBar, and that the default implementation of the dependency is Bar.

class Program {
    static void Main(string[] args) {
        IKernel kernel = new StandardKernel(
            new FooModule());
        IFoo foo = kernel.Get<IFoo>();



Case-Sensitive File Paths on Git for Windows: Stop Changing the Capitalization of m’Dang Branches

Git’s been a part of my daily business for a little more than a year now, and I ran into what can only be described as a shenanigan shortly after I started. The first feature branch I ever created was named something like Adam/a-feature. I did some work and merged it into master. Yay. Then it was time to work on a new feature, so I created another feature branch. This time, however, I decided that I wanted to use a lowercase “adam” as the branch prefix, something like adam/another-feature. Seems okay enough, right? Not so fast, my friend.

I was creating these branches in Bitbucket and syncing them locally with SourceTree. My new branch, adam/another-feature came down as expected, and I was able to do my work. Something weird would happen when I pushed my changes to the remote branch, though. SourceTree would report success, but it would indicate that I still had changes that needed to be pushed. Adding to my confusion, I could see that there were now two branches in Bitbucket: adam/another-feature and Adam/another-feature! What gives?

Well, it turns out this is due the the case-insensitivity of Windows. Branches are stored as files within the .git directory, and creating a new branch will create a file in the .git/refs/heads directory. So when I created my first branch, Adam/some-feature, it created the folder .git/refs/heads/Adam. Then, when I created my second branch, adam/another-feature, Git found and used the existing folder, .git/refs/heads/Adam, and used that.

Long story short, if you wish to change your capitalization scheme for branch prefixes in Git for Windows after you’ve already used a prefix with a different scheme, head on over to .git/refs/heads and make the change there!

Tracking Commits Across Branches with Git and SourceTree

When it comes to Git, SourceTree is definitely my tool of choice. However, I was surprised to find that there doesn’t appear to be any sort of built-in commit tracking to see which branches do and don’t contain a commit, similar to changeset tracking in Visual Studio. Now, that said, it’s pretty easy to do with Git, there’s just nothing that I could find baked into the SourceTree UI (Am I wrong? Let me know!).

So, if I need to do this, I click theĀ Terminal button in SourceTree and run one of the following commands:

git branch --contains 
git branch -r --contains 
git branch -a --contains 

The -r and -a parameters can be used to check just Remote or All (local+remote) branches.

Now, SourceTree may not have this functionality built-in, but it can be added easily with a Custom Action. Here’s how you can create a custom action to track a commit across branches.

  1. In SourceTree (Windows,, go to Tools > Options and select the Custom Actions tab
  2. Click the Add button to create a new custom action
  3. Enter a caption, and select the option to Show Full Output; for Script to run, enter the path to git.exe; and enter the parameters (note the use of $SHA)
  4. Click OK to save that bad boy

With the custom action created, you can run it by right-clicking a commit and choosing Custom Actions > Track in Remote Branches.

If you selected the option to show full output, the branches containing the commit will be listed in SourceTree.

Restore Nuget Packages

Sometimes, for whatever reason, I get a project that’s refusing to build because of missing references. But these missing references shouldn’t be missing because they’re Nuget packages!

Luckily, there’s a handy little command you can run from the Nuget Packager Manage Console. It’s one of those not-so-frequenly-used pieces of information that I need to lookup every time I need to use it… Perfect for a short blog post!

Restore packages for the entire solution:

Update-Package -Reinstall

Restore packages for a single project:

Update-Package -Reinstall -ProjectName