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

Comments

• Anonymous
  January 01, 2003
  PingBack from http://www.ditii.com/2009/06/23/app-v-4-5-circular-dependencies-with-dynamic-suite-composition/

• Anonymous
  January 01, 2003
  "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." Actually, if you publish these packages traditionally you still have to publish at least one OSD for dependency package as well as Management Server checks permissions based on published apps.. unless that has changed in CU1 or later? Of course, that OSD does not need to create actual shortcuts or anything but it must be published and/or assigned to user launching the primary package. br, Kalle

• Anonymous
  January 01, 2003
  While not really a circular dependency, I had to do a similar OSD setup for FactoryCAD 12, which needed to be suited with AutoCAD 2009.  Since FactoryCAD is more of a set of profiles and templates, and less of a stand alone program, no OSDs are created at sequence time.  So, I had to duplicate one of AutoCAD's OSDs, drop it into the FactoryCAD project directory, and do a bunch of tweaking to get the GUIDs happy and get AutoCAD to launch with a specific profile.  It was an interesting deployment, but for all its complexities, it was still pretty straightforward when compared to some of the fiasco's we have had to deal with (IronCAD 11, AspenOne 2006, Visual Studio 2008, etc).

• Anonymous
  January 01, 2003
  You can delete the shortcuts in the sequencing wizard without deleting the OSDs. Expand the individual entries in the left pane and click on shorcuts. Then delete each shortcut as well as each file type from the adjacent OU. This will simply remove the shortcut location placement information without deleting the OSDs and still allow importation and provisioning in th App-V MMC.

• Anonymous
  September 20, 2010
  How about AppA needing AppB as dependency, and inturn AppB needs AppC to run? (Multi level of dependency) is that possible in appv? Are there any challenges?