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.

Screenshot of custom commands

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?

  • Kris Coleman says:

    Nice write up, Joe.

    I too have encountered the issue with failed cleans when building. It’s always been a pain point with Xamarin. It used to be the infamous “IBTool failed”, but now that that issue is fixed I experience the odd clean state from time to time. Thanks for the suggestion on how to fix it.

    What really stuck out to me though is how you are helping yourselves out by putting the Git SHA for the latest commit in the about page for your beta testers. Great idea!

  • Juan says:

    I would like also to know about the git SHA part =D

  • Comments are closed.