Mode of Use - the poison in the App-V mix.
While the assocation can appear to work in testing - in the real world it does not work as the users require it to.
App1 physical (due to drivers. The app and drivers were not separated out) is launched outside the bubble
App2 has file association links to App1 and runs in a bubble. If App1 is NOT running then the FTAs launch App1 in the bubble ok. BUT if App1 is already running outside the bubble the FTA links fail because when they are attempted App1 outside the bubble can't see the file resources INSIDE the bubble.
e.g. ActivInspire=App1 and CuttingEdge=App2
Packaging (Preparing physical installs) and Virtualisation (preparing virtual applications) are generally regarded as very similar processes on the path to "application delivery" but in reality these two approaches are quite different. To avoid wasteful reworking exercises it is important to select the best and most suitable approach is selected during the packaging phase(physical or virtual). Application virtualisation is often seen as a desirable and as projects often try to set and predict percentages of virtualised applications that will be attained. Often the targets are unrealistic because the limitations of virtualisation are not fully appreciated early in the project.
The list of things that cannot be virtualised is relatively well known and typically includes
Drivers
Com+ components
Very Large >4Gb
Part of the operating system
Ideally, the physical or virtual decision should be made during the discovery phase or soon after the "packager" starts work. There should also be the option to interogate expert users or application owners about the mode of use that is applied to the normal use of the software.
Types of software that should start to ring alarm bells are:
Software that interoperates with other applications. See above.
Software that has ODBC connections that may need to be adjusted by advanced IT users.
Software that uses services that might sit quietly in the background. Virtual services only become available when the app has been launched. (Websphere)
In addition there are items that have no technical restrictions to virtualisation but require changes to the way users operate the software. (Addins) Is it reasonable to force (awkward?) changes to way users carry out their tasks just to accomodate the implemention of a new type of software delivery? Often user communities will not accept changes to way things users work which shoot yet another hole in the numbers of applications that can be virtualised.
Virtualisation will usually be the default approach unless there is a reason it is not possible. In reality the number of apps that end up on the cannot/should not be virtualised because suprisingly and disappointingly large. The numbers begin to make it questionable what value virtualisation brings considering the additional operational complexity necessary to run two application delivery technologies. One of the advantages of virtualising applications is that it can be relatively quick to run the sequencer and produce a virtual application. However all that effort can easily go to waste once it arrives in front of a user and it does not work as they need it to.