As above, a Diamond Dependency is when the dependency graph of a package forms a diamond shape. It makes upgrading components towards the bottom of the graph more difficult as dependencies have to picked so all package and dependency versions match or are compatible.
For a more concrete example, taking the diagram above, say there is a new nifty feature in Common we want to use in the UI. ServiceA 2.0 is built with Common 2.0, however there is no ServiceB 2.0, so to upgrade to Common 2.0 in the UI we must either upgrade ServiceB, abandon all hope, or determine if Common 2.0 can be brought in side by side with Common 1.0. The latter solution can cause a lot of issues if types in Common are shared between communication with UI and ServiceB.
The general solution is then to “level” the dependencies i.e. upgrade everything to lowest common denominator. In the above solution; the lowest common denominator is Common 1.0, so we must use Service A and Service B 1.0, as well as using Common 1.0 in UI. When Service B 2.0 is released we can upgrade everything to 2.0
For a better explanation of the issue, see here. http://www.well-typed.com/blog/9
Previously, for me, the solution to packaging and levelling in .Net was to use another platforms packaging tools such as Maven or use SVN Externals to bring in dll’s and manually update the externals property, working out the levelling myself. With the introduction of Nuget the .Net world now has a package manager which can do the levelling for you, and with a little bit of work lets you automate and integrate the build process of numerous packages; regardless of diamond dependencies.
This is a series of posts; broken into the following: