.Net & Xamarin Development on a Mac Part 2: Virtualization

0

Virtualization, who doesn’t like to talk about virtualization? No one I say. So you have 3 choices for virtualization when running on a Mac for your Windows VM’s, Parallels Desktop, VMWare Fusion and VirtualBox.

20120917_vmbench_teaserOver at TekRevue they did a great performance write-up comparing all three platforms and their comparative performance. Here I’m not really going to talk about outright performance, for that just go read that article, they did a far better job then I could.

Here is the TLDR, Parallels with a Windows VM on the Mac is a clear performance winner in startup times, graphics performance and ease of use.

 

But there is more to a virtualization platform then just pure performance. I’ve used both Parallels (versions 6 to 8) and VMWare Fusion 6 and 7. Besides emulation (i.e. the Xamarin Android Player and Genymotion) I haven’t, nor do I know anyone using VirtualBox for a mainline development VM. So I won’t be speaking about Virtual Box, it may be good but for our usage scenario there isn’t a lot of people doing it and thus when stuff goes wrong you can be SOL.

Pros Cons
Parallels Clear winner in perceived and actual performance More consumer grade/focus
Easy maintenance and optimization Lack of deep configuration options
Great integration with the Mac (Host OS) Lack of other OS support
VMWare Fusion Great support for a vast number of Operating Systems Slower performance and lower DirectX support
Deep configuration and tweaking options (i.e. Hyper-V) Not as frequently updated (Compared to Parallels)
Lots of Enterprise’y features (Migrations, Encryption, Sharing, etc) Sometimes complicated settings and options

So which one do I use? Currently I use VMWare Fusion 7. I made the switch to Fusion from Parallels during Parallels 8. During that time I felt that Fusion supported Retina displays better and it allowed for more configuration and tweaking of the virtual machine. I’m also a fan of how Fusion gives access to the VM through their menu. It’s far more compact and powerful then the corresponding Parallels one.

But you can’t go wrong with either choice in my opinion, they both work well. If you need the fastest performance you can muster or need the latest graphics support then Parallels is your best option, if you need rock solid stability and a deep field of configuration, tweaking and OS options then go Fusion.

In the context of what we are looking for virtualization for VMWare Fusion seems more popular. Xamarin uses it (all of the Xamarin University instructions have been on Mac with Fusion) and a fair amount of developers in the space seem to be following that same configuration. The benefit here is that the more people using that config the less problems there should be and the more help if an issue is encountered.

Resgrid is a SaaS product utilizing Microsoft Azure, providing logistics, management and communication tools to first responder organizations like volunteer fire departments, career fire departments, EMS, search and rescue, CERT, public safety, disaster relief organizations, etc. It was founded in late 2012 by myself and Jason Jarrett (staxmanade).

Full Time .Net & Xamarin Development on a Mac Part 1

0

Recently I started working full time on a Xamarin app for my job at Paylocity and for Resgrid a fair amount of my development especially when traveling has been on a Macbook Pro. So I’m approaching my new Xamarin environment with my previous scars and while it’s fresh in my mind I’ll share my experiences.

xs-iconThis will be a multi part series about my experience utilizing a Mac in .Net/Xamarin workflow. In this first post we are going to talk about the base hardware configuration and setup.

So where do you start off? This can be a daunting question and lots of things come into play. But first things first, you need a development hardware. When your doing Xamarin development you have a number of computer usage scenarios you can work off of:

1.) Full Time Dev on the Mac with Windows in a VM utilizing 1 machine (a Mac). The benefit of this pattern is that you only have 1 box to work on. The drawback is that you will be utilizing a VM for the Win8/Visual Studio parts and memory/performance is a concern. Only iMac’s and Mac Pro’s get you above 16GB of RAM. I would recommend 32GB for VM scenarios, and remember the Mac isn’t so good at reclaiming memory.

2.) Utilizing the Mac as a build host for Xamarin and working on a Windows machine full time, utilizing 2 boxes (1 Windows PC and 1 Mac). The benefit of this is if your doing .Net work most of the time you will have a first class experience (native VS development) but when your using Xamarin and need the iOS simulator you will have to switch to the mac (this will break your developers flow and add friction).

3.) Windows for full time development and if iOS isn’t a priority (yet) or a light priority you can utilize just a Windows machine for primary development and then use a service like MacInCloud for iOS building and testing. Also note MacInCloud is great for Team City and other CI, saves you hardware and allows you to easily offload Team City to say Microsoft Azure without worrying about tunnels into your network to access LAN hardware.

So why a Mac with a Windows VM or have a Mac at all? Well first if your development any iOS/Apple applications/games, etc your are technically and legally required to have genuine mac hardware in the mix somewhere. So why no Windows box with a Mac VM? Apple doesn’t allow it, and Hackintosh’s have a very tricky relationship with updates and XCode.

What will you find is that the first scenario is the most popular. Some co-workers went to Xamarin Evolve and almost everyone was running around with a Mac Book Pro. All my Xamarin University class instructors have been utilizing that scenario as well. This is also the scenario I would recommend. This is because it will be the least amount of hardware to manage and maintain, and it will reduce development friction and prevent flow killing context switching.

So now what mac do you buy? First I’d shy away from any i5 processor, most of them only have 2 cores (4 virtual if you include Hyper Threading). An i7 Quad core will increase your overall speed, give the host machine and the VM enough physical cores to access (because of my IT/SysAdmin background I’m not a huge fan of doubling up CPU extensive workloads on Hyper Threaded virtual processors).

Next is RAM, oh Apple and hardware component price gouging. This can get tricky, depending on the .Net workload. If you require SQL Server and/or multiple versions of Visual Studio open (i.e. you have 2 major solutions that you need to work on at the same time) you will want a minimum of 32GB of RAM for the Mac. This limits you to an iMac/iMac Retina or Mac Pro (ouch). If you only need 1 instance of Visual Studio open at a time and you don’t need SQL Server for any heavy lifting (i.e. a database many gigs in size) then 16GB is a good RAM size.

For optimal operation with a 16GB RAM size I’d recommend a minimum of 4096GB for the Windows VM or 6144GB if you need more memory on the VM (i.e. extensive use of Windows resources, like IIS or installed services). Give your Mac a fair amount of room to breath and utilize an app like Memory Clean to track usage and reclaim memory. If you only need 16GB of ram a MacBook Pro is by far your best bet, giving your developers a great system and portability. If you need 32GB give your VM 16384GB and keep the rest for your mac.

Also if at all possible get the biggest SSD/Flash drive you can. Keep your VM size down to the minimum (i.e. for all your installed programs, swap space, and some extra) you need and utilize shared resources as much as possible (i.e. shared folders on the hard drive from the Mac). This will reduce VM and host system load and startup times. Additionally utilizing shared folders you can quickly edit files from the host system instead of having to spin up the VM.

Multiple system solutions may be cheaper (i.e. a 500 buck Windows box and a 500 buck Mac mini) from the initial cost, but don’t underestimate the hidden\long running costs. Your developers will constantly be fighting with connection issues, maintaining 2 operation systems that are on 2 separate boxes, maintaining 2 separate hardware platforms and switching systems and thus contexts all of which will add friction and slow down the pace of development.

In future posts I’ll delve into Virtualization products, configuration, apps, and issues.

Resgrid is a SaaS product utilizing Microsoft Azure, providing logistics, management and communication tools to first responder organizations like volunteer fire departments, career fire departments, EMS, search and rescue, CERT, public safety, disaster relief organizations, etc. It was founded in late 2012 by myself and Jason Jarrett (staxmanade).

Developers and Local Admin, productivity lost in 60 seconds

0

Recently at a company I work for they started rolling our new Windows 8 boxes to the developers, sans local administration authority for the developer on the box. This of course is for the safety and security of the organization as a whole, what if the developer downloads a virus or other malicious software.

Lock-iconThe fact that this is still happening to developers in 2015 amazes me. Developers and IT should be a force for good in side a company but too many times I see these absurd lines drawn in the sand that just create a “us verses them” mentality, inhibit productivity, cause numerous issues and just overall create increased stress and friction for no good reason.

Let me be clear this isn’t domain admin rights, elevated rights to servers or infrastructure, just local administration rights on the developers computer. The days of developers, and frankly any IT worker, running around with domain admin/su/sa all the time for their primary account are long, long gone.

So why should you give your developers local admin rights on their development workstations, well here are my reasons.

  1. Drivers, Software, Tools, Environments and more almost all require admin permissions to install. Developers almost always have to install tools in a ad-hoc fashion. I recently needed to look inside a compiled .Net DLL to ensure it matched the emit of a build process. This required me to install Telerik’s JustDecompile to do this. Without local admin I couldn’t do this on the fly and the delay could have halted a production deployment. The toolset developers need today, will be different tomorrow, the world we work in advances too fast.
  2. Debugging is a dark art, not cut and dry. This is the most difficult thing to explain to non-developers and the business. Debugging is as much as on feel, trial and error or random chance as it is on pure knowledge or process. We’ve all been at the end of our ropes debugging an issue, tried something random and that lead to the discovery of the issue. A lot of debugging, like when attaching to other processes (i.e. IIS worker processes) requires elevation. I currently work on mobile applications, which means I use Fiddler to debug network traffic between a mobile device and our service stack. Can’t install Fiddler without local admin.
  3. Configuration Changes, Process\System Changes and Testing. We’ve all changed system settings to try and figure out an issue, for example giving ‘Everyone’ write access to a temp folder to ensure a log file get created, or trying to figure out other permission issues. I’ve changed IIS Settings/Modified Registry keys, etc. It’s impossible to properly convey all the things you may possibly need to do to get things to work or get around an issue.
  4. Every developer is different. Oh boy is every developer different. Developers are not factory workers or even IT workers, what we do is so very creative and tied to flow and proper mindset. To create an environment conductive to being creative it needs to feel like your space. That includes your system and hows it’s setup past just the colors of the desktop.
  5. It’s Insulting to most developers. Developers are usually intelligent, technical, skilled, passionate and opinionated. Most take pride in what they produce and how it’s produced. Locking them out of their own local machines or severely hampering won’t go over well, moral will drop, discontent will grow and your output will drop and turnover will increase.
  6. Chances are there is no law or regulations affecting the private sector that can be applied local admin. I’m sure there are some IT guys out there right now screaming “SOX” at their monitors, but no, that doesn’t apply to a developers local workstation. You find me a law or regulation for a private sector company that expressly limits local workstation administrator rights and I’ll buy you a shot of Macallan.
  7. If your worried about those evil developers installing bad software you’ve hired wrong. A developer can cause far, far more damage to your company. There is no control you can put in place that will prevent a developer from completely running a system if they wanted to. If you don’t trust a developer to use local admin properly why would you trust them with your product, or IP?

If there truly is a requirement then find a way that doesn’t involve adding more friction to a developers life. We deal with a lot of performance sapping, flow crippling, joy eating friction in general, to then be chained and inhibited from working to our full capacity is straw that should never end up on our backs, especially when so much rides on what we produce.

Go to Top