February 2011 - Posts

Moving a local Mercurial Repository to Bitbucket

I recently got a new laptop.  Part of the migration process was to move a few local Mercurial repositories into Bitbucket.  Since these are just “playing around” repositories, they’ll be private, but the beauty of Bitbucket is that you get unlimited private repositories.  This allows me to keep all of my little pet projects “up in the cloud” and it’s one less thing to migrate the next time I get a new machine.

The process couldn’t be simpler:

1. Log in to your Bitbucket account.

2. Under “Repositories”, select “Create New Repository”.

3. Enter the details for your repository.  Make sure you check the “Private” checkbox if you want this private.

Once your new repository is created, grab the URL (either the HTTPS one or the SSH one – depending on what you’re using) and copy it to the clipboard.  Now go to your local mercurial repository and enter:

hg push [repositoryURL]

Where [repositoryURL] will be the URL of your new repository (that’s why you copied it to the clipboard!).

The one last thing you’ll want to do is change the default path to your repository to be the Bitbucket repository.  So the next time you need to push changes up to Bitbucket, it will know where to go.  To do this, edit the “hgrc” file located in the .hg directory of your repository.  If there’s not a “[paths]” section, add one and then add a “default” key with the URL of your new repository (again, the clipboard comes in handy!):

[paths]
default = https://...

Done!

Technorati Tags: ,
Posted by PSteele | with no comments
Filed under: ,

Changing the Default Install Location of an MSI

A few months ago, I had to tweak an MSI installer.  It was installing into a specific directory (named the same as the application) underneath Program Files.  Since the location of Program Files can change from machine to machine, the MSI has a special token you can use for Program Files (as well as for the application name).  So the current value for “DefaultLocation” of the Application Folder was:

[ProgramFilesFolder]\[ProductName]

During installation, these tokens would be replaced by the actual location based on the current machine.

I needed to change this to a specific folder underneath the users My Documents directory.  I poked around the help file and I could not find where these special tokens (like “[ProgramFilesFolder]”) were defined.  Obviously, there must be some specific set of values that are available and I’m sure My Documents is one of them.

I finally found them documented so I’m posting the link here.  Hopefully, it will help someone else out.  Not sure where I found this link…

System Folder Properties

For me, it was as easy as changing the DefaultLocation to:

[PersonalFolder]\MyToolName\Application

Technorati Tags: ,

UPDATE: Finding the DefaultLocation property.

Posted by PSteele | with no comments
Filed under:

Setting up Windows Live Writer for Weblogs.asp.net

Once again, I’m on a new laptop and have forgotten how to set up Windows Live Writer to post to my Weblogs.asp.net account.  Thanks to Bil Simser, I’m up and running now.

I’ve found that a number of applications these days allow you to “export” your settings (FileZilla, Firefox plugins, bookmarks, etc…).  I think more companies should be doing this.  It makes migrating to a new machine a whole lot easier!

Posted by PSteele | with no comments

Using Lambdas for return values in Rhino.Mocks

In a recent StackOverflow question, someone showed some sample code they’d like to be able to use.  The particular syntax they used isn’t supported by Rhino.Mocks, but it was an interesting idea that I thought could be easily implemented with an extension method.

Background

When stubbing a method return value, Rhino.Mocks supports the following syntax:

dependency.Stub(s => s.GetSomething()).Return(new Order());

The method signature is generic and therefore you get compile-time type checking that the object you’re returning matches the return value defined by the “GetSomething” method.

You could also have Rhino.Mocks execute arbitrary code using the “Do” method:

dependency.Stub(s => s.GetSomething()).Do((Func<Order>) (() => new Order()));

This requires the cast though.  It works, but isn’t as clean as the original poster wanted.  They showed a simple example of something they’d like to see:

dependency.Stub(s => s.GetSomething()).Return(() => new Order());

Very clean, simple and no casting required.  While Rhino.Mocks doesn’t support this syntax, it’s easy to add it via an extension method.

The Rhino.Mocks “Stub” method returns an IMethodOptions<T>.  We just need to accept a Func<T> and use that as the return value.  At first, this would seem straightforward:

public static IMethodOptions<T> Return<T>(this IMethodOptions<T> opts, Func<T> factory)
{
    opts.Return(factory());
    return opts;
}

And this would work and would provide the syntax the user was looking for.  But the problem with this is that you loose the late-bound semantics of a lambda.  The Func<T> is executed immediately and stored as the return value.  At the point you’re setting up your mocks and stubs (the “Arrange” part of “Arrange, Act, Assert”), you may not want the lambda executing – you probably want it delayed until the method is actually executed and Rhino.Mocks plugs in your return value.

So let’s make a few small tweaks:

public static IMethodOptions<T> Return<T>(this IMethodOptions<T> opts, Func<T> factory)
{
    opts.Return(default(T));    // required for Rhino.Mocks on non-void methods
    opts.WhenCalled(mi => mi.ReturnValue = factory());
    return opts;
}

As you can see, we still need to set up some kind of return value or Rhino.Mocks will complain as soon as it intercepts a call to our stubbed method.  We use the “WhenCalled” method to set the return value equal to the execution of our lambda.  This gives us the delayed execution we’re looking for and a nice syntax for lambda-based return values in Rhino.Mocks.

Posted by PSteele | 1 comment(s)
Filed under: , ,
More Posts