App-V for Independent Software VendorsApp-V as a built-in feature in the OS, accessible to all Enterprise users without any additional costs (until now you had to purchase the MDOP).
This takes App-V adoption for large enterprise customers to a new level and is comparable in many ways with the introduction of the MSI technology in Windows 2000. However, since App-V is already used by thousands of companies worldwide and its mature Microsoft community is growing constantly, it's fair to say this change will have a greater impact.
App-V Adoption Going Exponential
The similarity between introducing the MSI in 2000 and the App-V built-in support from Windows 10 Anniversary is most important for ISVs which currently don't deliver App-V packages to their clients. They miss out on the chance of offering their clients with a better solution (because now the clients need to put their own time and money to convert the MSI/EXEs they get from ISVs to App-V format) and also increase the workload for their tech support teams which constantly struggle with problems from users that try to convert the applications.
Tip for ISVs: If you offer your customers better solutions they will be happier and come back to purchase updates or recommend your software to friends in other companies.
Following, we'll talk more about the advantages of App-V, so that any ISV can understand why it's so important for enterprise clients. If you're already convinced that App-V is valuable, than you can skip to the Application Requirements section.
The short list:
- Run multiple versions of an app side by side without conflicts
- No conflict on shared resources between apps from different vendors
- Reduced testing times (because there are no app conflicts)
- Simplified applications updates
- Improved user experience - especially for VDI environments
Let's argue on the above list a little bit, providing more details. I know, you might say that all these are not advantages for ISVs, but they actually are. First off, by providing an App-V package, you make your solution way more reasonable and attractive than your competition's.
All App-V applications run inside of a "bubble-like" environment and this allows the OS to run multiple versions of an app without resources' conflicts. This is possible due to the App-V client that redirects all the calls for each app in a dedicated container. The same bubble environment eliminates the conflicts with apps from different vendors when accessing shared resources.
One of the biggest headaches for IT departments is testing that the applications work as described by the software vendor in their company environment. This is because with standard MSI/EXE deployments, conflicts appear all the time, with apps overwriting shared DLLs, or a folder with application information getting "cleaned up" by mistake when another app is removed. The list goes on.
Bubble environment is here to save the IT teams again, the app containerization allows each app to keep a unique image of the files it creates and also of the files and registry that it can "see" from the main OS. Yes, you can configure an App-V application to behave as if certain resources are not found on the machine, even if those files/registry exist on the user's system.
Most applications, when uninstalled, leave "garbage" on the end user machines, be it application data files, user resources or incorrectly tracked shared resources. The really bad part is when these apps get uninstalled and delete resources used by other applications, thus breaking them.
The bubble brought by App-V packages prevents all these situations and make uninstalling and updates deployment seamless, optimizing the speed at which large companies can bring their software fleet up to date with the latest software tools.
VDI based environments always struggle with their network load and high loading times for user profiles at logon. No matter how fast the network is, the more applications a user has, the more it will take for them to be pushed over the LAN on the machine where the user has logged on. That is GB of data sent over the lan every time, for each logon.
The problem is that in most of the cases, the user launches just a few applications, like his chat, Word and Internet browser. Most of the apps should not be downloaded if they're not needed.
App-V packages are streamed to the end-users' machines by a publishing server. The way the apps are packaged, allows the server to optimize their streaming so the logon for the user gets done much faster. The App-V server doesn't stream the entire application until the user tries to launch it, it only streams the essential parts of the application and its entry points (shortcuts, files association, etc). Once the user launches an app, the server pushes it completely and a cached version of the app gets stored locally.
The streaming options are configurable, so the IT team can always decide if apps are streamed 100% from the beginning, or on demand, depending on the available infrastructure and business requirements of the company.
There are no special requirements for a desktop application to be suitable for App-V packaging. You can have the application written in C++, C#, Java or any other language you prefer, nevertheless there are some showstoppers which any ISV should know about when thinking about supporting App-V.
1) You cannot virtualize a driver. You can still deliver the rest of the application as an App-V package, but the driver must be delivered separately (installed with a MSI or script). IT folks already know this so if you give them the package and the driver they will know what to do.
Advanced Installer has an automatic fix for this, it detects the driver from your project, excludes it from the App-V package build and places it in a MSI next to the App-V output.
2) You cannot use hardcoded paths in your code. There is no workaround for this, the only solution is to have that code re-written and to make sure you are using known folder IDs from MSDN.
3) You cannot have a service that starts at boot time. App-V requires a user logged in to launch an application.
4) You cannot use COM+ or COM DLL surrogate virtualization.
5) Licensing information. If your application uses machine information like MAC address or another hardware signature to offer the users a trial period, some changes must be done to make sure the end-users can activate your application at first launch, manually or by using a script.
More details can be found in this Microsoft blog post.