Common App-V Myths

April 2021

There are perhaps more misunderstandings around App-V than any other application packaging technology. These are the most common we encounter with our clients.

Myth 1 - Creating App-Vs is quicker than creating MSI packages

This was a common catch phrase in the early days of App-V (going back to when it was Softgrid) but meant faster than new MSIs via snapshot. Most vendors have for many years now provided their software with MSI installers, or setup exe installers that are simple to configure for silent install. Also while creating an App-V sequence is simple, solving the compatibility problems of an application running in an isolated container can be very time consuming. If you limit that troubleshooting then sequencing will save some time over traditional packaging, but if you need as many to work as possible it can actually take much longer.

Myth 2 - Most applications can be App-Ved

Our experience shows the documented App-V limitations are far from a complete list of why applications are incompatible with it. There are countless ways developers can code their application to not function properly running in the App-V container. It's best to think of App-V as a new OS. In the same way that moving software from Win 7 to Win 10 can cause it not to work properly, moving from Win 10 to Win 10 with App-V can do the same. The vendors tell you the OSs their software has been tested on, and it won't include your version of App-V. Workarounds to many of these issues are possible, but take time as we talked about in Myth 1.

Myth 3 - Applications are virtualised with App-V

Well not really, not as most IT people think of it from their experience with virtual machines anyway. With that the hardware is virtual and has a real operating system installed on it. But with app virtualisation the application is real and so is the OS it's installed on. The "virtualisation" is that the application is installed into a container, or sequenced. When that sequence is deployed to a machine and the app started, it runs isolated from the OS and other applications.

Myth 4 - Applications run the same as an App-V

App-V isolates the application from other apps and the operating system. This inevitably causes complications, especially for the many applications intended to interact with each other. What's more, performance running the application is generally a little slower as an App-V, even when fully locally cached. This can be quite noticeable with applications that are on the slower side anyway and on VDIs that are under resourced to run as quickly as a physical desktop in the first place.

Myth 5 - App-V solves OS compatibility problems

As the App-Ved application still runs on the real operating system (see Myth 3) its OS compatibility is unchanged. In fact you now potentially have new compatiblity issues with App-V. The only OS compatibility issue App-V can solve is where the app requires opening permissions to work. That can just as easily be solved with selective changes to file and registry permissions in a normal package.

Myth 6 - App-V makes application management easier

Keep in mind you will continue to have many applications not in App-V format (see Myth 2), so in effect you still have all the old challenges and are now managing an additional deployment type. What's more, the way App-V hides application files and reg keys makes troubleshooting more difficult for your BAU desktop support people. App-V has also been touted as solving "DLL Hell", but that's rarely an issue today anyway. Modern programming technologies such as .NET don't need the shared file and registry that caused so many problems when COM was dominant. The design of the MSI system itself safeguards against downgrading or removing shared resources when used correctly.

When is App-V the solution?

So given these limitations of App-V in real world use, when is it the right solution? The most popular scenario for App-V today is delivering applications to pooled VDIs using streaming or Shared Content Store (SCS also provides significant savings on disk space). In this case App-V is being used primarily as an application deployment system. However, it's important to have realistic expectations about how much you can App-V without the effort becoming uneconomical.

App-V is also an isolation technology and as a result has been popular for Citrix XenApp published app servers. The ability to safely install large numbers of applications together on a server has provided major returns on investment by reducing "siloing", lots of often only slightly different builds for various business units. But as application coexistence has improved (see Myth 6) this has become less common anyway.

Isolation can also be useful anywhere multiple versions of the same app are needed. Perhaps the latest is missing some functionality and the users want both it and the previous version installed. Often that wouldn't be possible without App-V. It can likewise be a workaround in rare cases where two unrelated apps won't coexist, perhaps because one needs a specific version of a DLL. Installing a few App-Vs like this doesn't need any additional infrastructure, SCCM can be used or simple PowerShell commands.

Send us your comments and feedback on this blog post.

© Fenix Consulting Pty Ltd