Circular dependencies with Dynamic Suite Composition and App-V 4.5

If you’ve been using App-V and it’s cool Dynamic Suite Composition (DSC) feature for a while then I’m sure you’re already aware of the power and flexibility this provides by allowing you to combine multiple virtualized applications into a single virtual package by creating dependencies between the applications themselves.  For example, using the DSC Tool you can specify that Package A requires Package B, and if Package A is launched it will automatically launch Package B within the same environment.  But what if I have a situation where Package A requires the dependency to Package B, but you also want to create a dependency where Package B also requires Package A to run?  This is what we call a circular dependency, and if you try something like this within the Dynamic Suite Composition Tool you’ll get an error that looks something like this:

So why is this a problem?  It’s a problem because dependencies aren’t transitive (at least, not in the current release), and while a circular dependency will seem to work there are more subtle problems with this.

When package A depends on package B, a virtual environment (VE) is created at runtime that contains all the virtual resources from A and B’s packages, and changes to the VE are associated with A’s package when they are saved. When B depends on A, a second VE is created that also contains all the resources from A and B’s packages, but changes to the VE are associated with B’s package.

So you end up with two separate VEs. That’s the first problem. If you launch apps from A, they end up in a different VE from B’s apps and they may not interact they way you expect them to.

Each of the VEs has the resources from A and B loaded in a different order. That’s the second problem. Some resource in A and B may overlap, and the conflict will be resolved differently depending on which VE you’re running in, so you can get weird and inconsistent app behavior.

The VE state is persisted under the primary package. So apps running in the VE where A depends on B have their state saved separately from apps running in the VE where B depends on A. This is the third problem.

These problems are exacerbated when you consider that a user directly launching a package B app will get the app running in B’s VE, but if the same app is launched from within a running instance of a package A app, it will run in A’s VE… separate from other B apps, with a different ordering of resource layers, and with state persisted to a different place.

For simple apps, this may seem to work fine, but it can quickly become a big mess. What we suggest is that when you have two apps that always need to be together, you choose one to be the primary package and create OSD files for the apps from the other package in that primary package so that all apps are always launched the same way (in the same VE, with the same resource layering, and with changes persisted to the same place).

So if you decide to make A depend on B, you sequence B first, but use the sequencing wizard to remove any shortcuts or file types it creates. Then you sequence A, and add any shortcuts or file types for B that you want users to see. You’ll end up with a bunch of OSD files for A and none for B. At runtime, users will always launch apps with shortcuts/file types from package A, so they’ll always get the same VE, same resource layering, etc.

Hope this helps,

Eric Jewart | Senior App-V Development Lead