Application Virtualisation: What is all that?

With the recent launch of InstallAware’s Application Virtualisation (or Virtualization, depending on how you feel and where you are from!) I figured that it was about time that I stopped and looked at it all again.

Application Virtualisation is not a new technology.
VMWare have a tool called ThinApp out there that does exactly that.
Microsoft have a system called App-V (can you guess what that stands for?).

So why another one?

Quite simple really.

VMWare’s ThinApp product is probably the closest match to InstallAware’s tool – however, carrying a minimum price tag of $6050 kind of puts most smaller developers – and I include myself in this bracket – off even contemplating looking at application virtualisation or even from talking to clients about it.

Microsoft App-V on the other hand takes a different approach to it. As ever with Microsoft, it’s more an enterprise offering – building on top of a companies existing infrastructure of terminal services, active directory and the like. However, if you have all that infrastructure, and you want application virtualisation totally in house purely for application version control, then this is probably the best route to go.

But what if you want true application virtualisation – something that you can actually easily build, copy onto a memory stick and then run it anywhere: Maybe at home on different machines, maybe at work, the internet cafe, the library – pretty much anywhere.

Introducing InstallAware Application Virtualisation.

The first thing that struck me with this app was the price. It’s not a bank breaker. It’s $999. Hmm. What was that VMWare figure again? Ah yes. So it’s $999 vs $6050 ? And have I mentioned that it’s royalty free?

Both products work by redirecting access to the file system and the Windows registry to a series of files. Both can use setup capture to attempt to automatically build your virtualisation package.

So what are the differences?

Well, I have to admit, it’s been a while since I looked at this arena. It has to be just over a year since I last looked ThinApp, and dismissed it rather quickly. It was just too clunky, too restrictive and I could only ever get my basic applications to work. Every time I tried to virtualise a .NET application (come-on, who ISNT working in .NET apps these days?), it just didn’t work. Being an independent consultant and developer, I don’t have time to waste on applications that make no sense, and just plain don’t work – or come with suitable documentation.

Anyway, I downloaded the InstallAware offering, installed it and immediately noticed that it’s using an existing virtualisation toolkit – called BoxedApp. Now, in my opinion this is a good thing. Instead of trying to re-invent the wheel, they have gone with a company to share knowledge and expertise, and hopefully deliver a winning combination.

My setup for experimenting is fairly limited as I’m just wanting to scratch the surface here:

Builds are on a Windows 7 Ultimate laptop with Microsoft Visual Studio 2010 Ultimate and all the updates (so all dependencies).
Tests are on an older Windows Server 2003 SBS machine, which has .NET 3.5 at most, with all updates. Nothing else – never run applications on here as it’s a headless box.

The first application that I thought I would “virtualise” is a simple C++ “Hello World” application. Nothing fancy at all. For those techis reading this, it was a fully linked binary, with minimal dependencies just to keep things simple.

InstallAware Virtualisation Screenshot

My initial reactions are the main InstallAware Virtualisation application’s user interface could do with a little bit of TLC. It is a little rough, and not terribly intuitive. The input EXE is actually the program you want to virtualise, and you do not have to list it in the files (I’m guessing this is done implicitly). Instead, you only list the files (and registry keys) that your application needs here.

The resulting packed application was around 1.5Mb – whereas the original app file was around 500Kb – so it looks like we get around a 1Mb runtime overhead – not bad at all.

The packed app was copied onto the server and ….

image

Now this could easily be the application running on the machine natively, without virtualisation, so I wanted to try something far more interesting.

Let’s try the same sort of application, but built in .NET 4 on the machine. Just to prove, this machine does not have (and will not have!) .NET 4 installed on it:

.NET Runtimes Proof

Application project settings in Visual Studio 2010:

image

Running the result on the server directly results in the expected .NET version error:

image

In order to get the Virtualisation tool to identify the requirements for .NET 4 (and to work out what registry keys and files it needed to package), I had to setup a “clean” virtual machine, install the Setup Capture tool and then install .NET 4. Why? Quite simply, the prospect of manually feeding the settings into the builder app was not my idea of fun. There are no presets, even for common frameworks like .NET and Microsoft Visual C++.

I should point out that you do not have to mess about installing InstallAware Virtualisation onto your capture machine – you only need to copy mpa.exe and a couple of text files over and run that (and follow the prompts!).

First step in prepping the virtual machine, was to install .NET 2 –> 3.5.

Then I copied mpa.exe, regexclude.txt and fileexclude.txt onto the machine and fired it up. The initial scan completed fairly quickly.

During the build, I opted to make a portable version of the project – this is a special type of project that includes all the files that the virtualisation tools have detected you need, so that you can move it to another machine and keep working – ideal if you are using Virtual Machines for your snapshots.

Unfortunately, this process threw up lots of errors – all around trying to capture the files and information for .NET 4.0. Ignoring these errors resulted in a project that did not work “virtually”. :(

So my conclusions!

It’s a very good start, but it really needs polishing. It’s certainly functional, and does the job – but it has too many hoops that you need to jump through. Mind you, saying that, it has far FEWER hoops that VMWare’s ThinApp!

At this time, in my opinion, it seems like an ideal low cost application virtualisation toolkit for native applications. With a little bit of work (or if you an guarantee the .NET framework is installed on your user base), it would be fine for your .NET Apps too.

What I would like to see though is:
- Pre-set .NET Runtime configurations in the builder GUI
- Drag and drop support for adding files AND folders
- Import support for loading large numbers of registry keys
- Better GUI
- Context sensitive help
- Ability to define platform requirements

 

Disclosure
Now, just before anyone comments, I’m no stranger to InstallAware as a company. I’ve been an avid user of their installation product for a good while and I have done a stint at helping with technical support. I’ve watched the company grow and helped where I can – but that does not mean to say that I always take the “party line” so to speak. 
I’m a developer. That’s my primary job, and that’s how I earn a living. During my work, I encounter a lot of companies – from companies building installation tools (InstallAware, InstallShield – sorry Flexera), virtualisation companies (Microsoft, Citrix, VMWare) and so forth. Every now and again I encounter something which I feel is a game changer; either opening new doors for smaller independent software developers, or perhaps taking an unusual approach to improve an existing situation – much like how I feel InstallAware is a major improvement of InstallShield. Much of my early career I spent working with InstallShield and hated it – and switching to Inno Setup.