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…

A Handy MSDN Bookmarklet

04/12/2011 Leave a comment

If you’re like me, you don’t do all of your coding in Visual Studio.  That’s when you start to miss the convenience of just hitting F1 to bring up the MSDN documentation for a specific class.

To bring that simplicity to your browser, just paste the following into the URL field of a manually created bookmark:

javascript:(function(){c=prompt("Enter the fully-qualified name of a class, method, property, etc.:","System.Object");window.location=""+c+"(v=VS.100).aspx"}());

Mysterious CALayer Object Proliferation Caused By Core Animation?!

07/15/2009 Leave a comment

I have been reviewing some UI code that I just completed. It’s my regular practice to check for leaks, etc., so that I can verify that my code is doing what I think it’s doing. I typically fire up Instruments running the Leaks monitor, and not only review any leaks that are found, but also review Object Allocation behavior.

I plugged a couple of leaks that sprang up, but I still could not figure out why object allocations were growing to infinity (albeit at a snail’s pace). I could launch my app and just let it sit idle and CALayer objects were just proliferating. I narrowed the problem down to a simple background [UIView animation] block. Surely Core Animation didn’t leak, right?

Turns out, the answer is: not really. Thanks to Apple Devforum poster Rincewind, we now know:

You are probably seeing a bug in ObjectAlloc. You can confirm this in one of two ways

1) Examine the memory address of these “leaked” objects – they will probably all be the same (or a small set of addresses).

2) Add the Memory Monitor instrument from the library and watch your application’s Real Memory – this is generally a far better indicator of how much memory your application is using in total anyway.

Sure enough, he was right! The objects pouring into the list on Instruments all clustered around the same few memory addresses. Watching the physical memory confirmed that, despite the ever-growing heap in Object Allocations, physical memory was holding steady.

Whew! But Grrr! Hopefully you can avoid the frustration (until it’s patched).

Happy Debugging!