This was a tough one to put a label on. Here I’m referring to commonly shared dependencies. This could be Java, Flash Player, VB runtimes, Access runtimes or other forms of runtime, middleware or even just a widely required pre-requisite\dependency. As the title of my blog post might suggest, App-V has limitations. Certain application will not work when sequenced. So what happens when your application cannot be sequenced and say, it requires a vb runtime. You have sequenced this vb runtime for use with other applications. Now, you’ll need to package the vb runtime and deploy it locally to cater for this other application which cannot be sequenced.
With App-V 4.x, you’d have no other option but to re-package for a local install BUT with App-V 5.0, we now have the RunVirtual feature and with App-V 5.0 SP3 this feature is much more flexible as it allows for publishing using User Publishing or Global Publishing. RunVirtual will allow you to set a registry key which will enable your locally installed application to see and leverage your virtualized Middleware\Runtime\Whatever. For more about RunVirtual check this out HERE Now, using RunVirtual can require some proper planning. It’s a little limited in that you may need to create connection groups with many different applications (if multiple virtual applications are required) which are required by the local app and set the RunVirtual for the primary application which will invoke the connection group. I know, it’s confusing, right!?
There’s also the option to use the /appvve as documented HERE if the commonly required local application has a shortcut which is invoked. Basically you set an argument in the Target of the local application shortcut which points to the virtual application ProductID GUID_ Version ID GUID. It works but it’s a little messy!
As per the graph, I suggest that if your application is Middleware, Runtime, something which is commonly required by applications there’s a bit of decision process I’d consider. Is the application shared by virtualized and installed apps, if it’s not and you know it’s not going to be, go ahead and sequence. Now, if your application is shared by virtual applications and locally installed applications I’d suggest that you could still sequence the application and then use RunVirtual or the appvve switch to support the local applications that require it. If the application is middleware but you don’t want to use RunVirtual or the appve parameter due to the messyness or possibly the limitations of RunVirtual, go ahead and deploy as a local install. If suitable, including the other dependent applications you could deploy these in XenApp/RDS is the app is not required offline.
