Yeah, it’s difficult, error-prone and somewhat buggy.
Imagine following scenario:
- Library application X v1
- Main application Y, depends on X
- You need to upgrade X v1 to v2 by first uninstalling old version and then installing new version
The only way I’ve seen this work is deleting dependency, deploying X upgrade semi-manually and then setting dependency to v2. Any other attempt will get you “Rule is in conflict with other rules” in deployment monitoring as agent will refuse to remove v1.
The second scenario:
- Library application Z v1
- Main application Q, depends on Z
- You need to upgrade Z to v2, no uninstall is necessary
This was explicitly added in 2012 R2 SP1 that made this scenario possible if v2 superseded v1. In real life I’ve found this very unreliable. The worst I’ve seen was agent gobbling up GBs of RAM grinding systems to a halt. Application detection got stuck in loop and leaking memory as some old applications were set to depend on v1 and some newer on v2. In better cases – good old “Rule is in conflict with other rules”.
There used to be a workaround. Add both Z v1 and Z v2 to the same dependency group but clear Install Automatically flag on v1. This seems to have stopped working in 1602 or 1606 as client will stop dependency processing if v1 is not found. I only tested this very briefly in new builds so do not trust me on that. Might be a bug or maybe original behavior in 2012 R2 was buggy…
This makes you wish for something like MDT application bundles. Group Z versions into bundle and create dependancy on bundle.
Generally application model is great but with a lot of annoying gotchas. Or maybe it’s just me…
Leave a note if comments if you’ve found a better way.