Supercharging Xamarin Studio’s Play Button with Custom Build Steps

As my team’s current project has morphed from a heavy Ember.js app running in a thin PhoneGap web view into a thin Ember.js front end driving a rich Xamarin back end, we’ve had to change our approach to build automation. Here’s how we leverage custom build steps in Xamarin Studio to make our workdays easier.

Keeping Things Really, Really Clean

Xamarin Studio for macOS is an incredible tool. It makes developing cross-platform apps feasible, and even enjoyable. But like many powerful tools, it has its…quirks.

From time to time, the clean step of a build will fail, silently and inexplicably. We first discovered the IDE bug while diagnosing what initially seemed like a bug in our application. We tried everything we could think of to fix the issue, but no matter what we changed, the bug persisted.

After hours of pair debugging, we threw up our hands in desperation and decided to throw out the entire working directory (after stashing and backing up, of course) and start from scratch. To our surprise, the trick worked. Upon investigating a bit further, we found out that Xamarin Studio had gotten stuck in an internal state where it didn’t think that it needed to recompile some of our code when we pressed rebuild.

To temporarily mitigate the problem, we added a simple rule to the Before Clean step of our Xamarin build. It invokes a Make target which forcibly removes the bin/, dist/, and obj/ directories from each of the projects in our solution. Normal builds don’t trigger a clean step, so most of our builds aren’t impacted. But when Xamarin gets confused, we no longer have to worry about its internal state. We just press Clean All and get back to work.

Making Builds More Useful

Whenever we release a new version of the app, we add the current Git commit identifier to an About screen that’s easy for beta testers to access. That way, when a tester in the field runs into an issue, they can email us a short string and we’ll know exactly what version of the code they were running.

Our process for updating the hash was a bit archaic. Just before cutting an alpha, the releasing developer would copy the commit identifier into a template file and then proceed with the release. It’s a really simple task that’s ideal for automation, but it took so little time that it never bothered any of us enough to do anything about it.

While we were digging around in Xamarin Studio’s custom build steps, we saw an opportunity to eliminate this manual step and remove a tiny bit of friction from our release process. Now, instead of relying on an error-prone hominid to copy the commit identifier, we use Before Build to do the job. It’s a minor optimization, but one that eliminates friction and opportunity for error and makes our lives just a little bit easier.

Both of these automations could have been done many, many different ways. We found Xamarin’s custom build steps to be a convenient hook on which to hang the build automation for this project. How do you automate your builds?