Archive for the ‘Tools’ Category

Build Transforms for App.config (and Other Xml Files), FTW!

07/07/2012 8 comments

Like most .net devs, I fell in love the the web.config transforms that were introduced in VS 2010. And like most .net devs, I miss having them for other types of files, say, like App.configs. There is the SlowCheetah VSIX, but this imposes yet-another-build-environment-dependency on the downstream consumers of your source code. Since I’m working on a project that will ultimately be released as open source, that strikes me as one more barrier to participation, and one more thing to make automated deployment a pain. So here’s how I went about implementing it.

Read more…

Debugging Windows Azure (without Intellitrace)

03/14/2012 Leave a comment

If you have, or have access to, a workstation with an x64 version of Visual Studio, you can configure Azure diagnostics to collect and copy the crash dumps to Blob Storage:

// Must be called after diagnostic monitor starts.

You can then download them (using a tool like Azure Storage Explorer) and debug them locally.

Azure Development on x86 Windows

03/14/2012 Leave a comment

If you are planning on doing any appreciable amount of work developing Azure applications using Visual Studio, and are still running x86, you should consider migrating to x64 Visual Studio sooner rather than later. This is even more the case if your application relies directly, or indirectly, on unmanaged code.
Read more…

Meet blaze: C# without cruft!

01/11/2012 Leave a comment

I’ve officially renamed SharpPad as ‘blaze’. Same scripting core host, but a new icon, new installer URL, and thanks to Brandon Berry, new features!

For a limited time, you can download install directly from
You can still get the source from (although I’ll be moving the repository soon).

NOTE: If you have already installed SharpPad, you’ll need to install blaze from the location above in order to received auto-updates.

Wrap Any Class in Dynamic Goodness

08/11/2011 1 comment

I use the decorator pattern like it’s going out of style. Not really. I would, though, if it didn’t tend to lead to class explosion. Instead of using it in a broad way, I tend to reach for it in a couple of common scenarios:

  1. when someone else’s object doesn’t do what I want it to, and isn’t open for extension, or
  2. when I want to pass an object to a method that wouldn’t accept the object otherwise.

However, decoration can be tedious, can violate the DRY principle, and can lead to lots of little wrapper classes lying around that just clutter a project up. What if we can prevent that? Read more…