VMWare Workstation and Xamarin Development: It could have been so good

I’ve been doing Xamarin Development for almost two years now.  Until a few weeks ago my preferred environment has been Xamarin Studio on a MacBook Air, which worked fine for the mobile apps themselves but not so well for writing and editing the Azure/ASPNET MVC service layers; for that I really need Visual Studio.  I considered getting a MacBook Pro and running Visual Studio in a Parallels or VMWare Fusion VM, but what I really wanted was the ability to run several VMs at once, especially dedicated VMs for SQL Server and SharePoint.  This latter consideration rules out the MacBook Pro as we know it currently: 16GB of RAM isn’t enough for MacOS and Xamarin Studio, a VM for Visual Studio and IIS, and a VM for SqlServer (16GB is barely enough for Chrome, but I digress).

Since I don’t see Apple releasing a MacBook Pro with 32GB of RAM anytime soon (or selling it for less than $4000 when they do), I opted to get a Lenovo P50 with a quad-core i7, 64GB of RAM, and a 1TB NVMe SSD (for just $2200 — top that, Apple!).  Part of the goal here is to have separate and isolated client VMs so that the work I do for Client A is in it’s own VM, Client B in another VM, etc.  This is especially useful when a client requires archaic versions of Visual Studio or Sql Server (as recently happened on a DTS 2000 to SSIS 2012 migration project).

To accomplish this VM strategy I downloaded a 30 day trial of VMWare Workstation Pro 12 and used the last Windows 10 Pro license I had on hand.  I created a pristine base image and then created a Linked Clone for the first client project.  In that clone (let’s call it Client-A-Stable) I then installed Visual Studio 2015 Professional, all of the bits for Xamarin development, and all of the Android SDK components and tools for APIs 19 – 23.

Now the fun part: programming!  I pulled down the code for the client’s Xamarin app, performed the initial build (made longer by Nuget restores and some “works on my machine” config updates to get things to run) and was ready to launch the app in an Android emulator… which is where this story goes wrong.  On Windows, there are three choices in Android emulators: the Google supplied emulators (slowest), Genymotion (fast but requires Virtual Box which I would prefer to avoid), and Microsoft’s Hyper-V based emulators for Android which are the fastest option available.  I installed the Microsoft Hyper-V emulator and upon launch was met with the first problem: Hyper-V support in a VMWare Workstation VM.  Officially, VMWare doesn’t support Hyper-V currently though they do have an unsupported Hyper-V mode which makes the operating system in a VM think that it’s running in a proper Hyper-V environment.  Okay, let’s give it a try now: no-go.  Even though, per VMWare’s sparse documentation on the topic, Hyper-V features should be working at this point, the Microsoft Hyper-V emulator refused to run, with a dialog box citing that Hyper-V support was absent.

No big deal, I still have a couple more options left. Next I created a Linked Clone from Client-A-Stable (Client-A-Genymotion) and downloaded and installed Genymotion. More dramatically, Genymotion, which is built atop Virutal Box, detected that it had been installed in a VM and flat-out-refused to even try to launch. Okay, delete that Linked Clone, at which point I’m thinking this linked clone business is awesome: if I want to experiment with something that could potentially muck up or destabilize my VM, just create a linked clone, give it a try, and delete it if the experiment fails.  But as nice as that is, I really need an Android emulator to work sooner than later or I’m going to be up a creek fast!

Last option: the Google supplied emulators. Initially this was a no-go (no Vt-x support was detected). Fortunately the client had a physical Android device I could attach to my laptop and use for debugging until I could get the emulator mess figured out.  After a couple weeks I discovered that having Hyper-V enabled in the VM (or the base operating system) makes it appear to apps that VT-x is not available even though my i7-6820HQ CPU most certainly has this ability. The solution, as I learned, is to turn off Hyper-V in the VM and specifically enable emulated VT-x, at which point I could FINALLY get the Google/Intel HAXM Android emulators to run.  Well, “run” really isn’t the right term… crawl is more accurate.  So slow that clicking on the “apps grid” button allowed me to see in janky detail, over a period of a few seconds, the animation of the button grow to full screen, totally cover the whole screen of the emulator, and then do an animated disappearing act, revealing the grid of apps loaded in the emulator.  And this was after waiting more than a full minute for the emulator to load. There are only two words to describe this state of affairs: completely unsatisfactory.

In summary: the high performance Hyper-V android emulator won’t run in a VM even though it’s in hyper-v mode, and VMWare won’t support VMs in this mode so I’m on my own and out of luck on this option.  Genrymotion is a no-go because it detected it wasn’t running on the base operating system and refused to even start. And the Google/HAXM emulators are a no-go because they take too stinking long to actually do anything… which will always lead to other things. At least for this client engagement I can use their physical Samsung device tethered to my machine for development and testing, and while this certainly work, there are a few problems. First, this device belongs to the client and if they suddenly have a need for the loaner device I have then I’m on my own again. Secondly, this device represents only one of the API levels being supported for this app.  The app is officially supported on APIs 19 -23 (and 24 before the end of the month) but the testing device I have is API 22.  Lastly, by being restricted to the physical device I’m locked into thinking of the app in that aspect ratio and screen size only.  You always need to make sure the app looks and acts well whether you’re running on a 10″ tablet or a 4″ Nexus 4. Emulators are perfect for this kind of smoke testing — but I cannot run an emulator and get work done in a reasonable amount of time.

Ideally I would be able to run the Microsoft Hyper-V emulators in a VMWare hyper-v-enabled VM and just get my work done quickly, but this doesn’t seem to be an option with the current state of VMWare Workstation.  Looks like my only recourse is to install Visual Studio and all other once-per-client software requirements in the base OS (Windows 10 Pro) and hope the time between erase-and-reinstalls on this machine is minimal.