Dynamics AX Sustained Engineering: Understanding Application Dependencies in Dynamics AX 2009 Hotfixes

[Blog bot]

Источник: http://blogs.technet.com/b/dynamicsa...-hotfixes.aspx
==============

The Dynamics AX 2009 servicing process creates a dependency between the affected objects when a hotfix is created. For example, if a fix modified two different classes Foo() and Bar() then a dependency is created between these classes so that whenever one is included in a hotfix the other gets pulled along as a dependency. This is required to ensure the integrity of the hotfix contains the entire fix along with all encompassed bug fixes so that we don’t regress on previously shipped functionality.

An encompassed bug fix is one where an application object is modified as part of a fix but the same object was modified as part of a previously released fix. In this case, when a hotfix is generated for this new fix it will automatically include the previous fix (due to its cumulative nature) and thus any dependencies related to the previous fix must also be included in the hotfix.

As an example, assume you have the following two hotfixes:

Hotfix #1 modifies Foo() and Bar()
Hotfix #2 modifies Bar()

Because Hotfix #2 is made against a version of Bar() that already contains a previous fix (Hotfix #1), when Hotfix #2 is packaged it includes the latest version of Bar() but also pulls in Foo() as a dependency (due to the encompassed fix from Hotfix #1).

As more encompassed fixes are included in a hotfix the number of dependencies included in a hotfix are likely to also increase.

What further complicates the dependency calculations is that changes that overlayered in the higher layers (such as GLS) will require the overlayering to be resolved in its respective patch layer. As a result, dependencies need to be taken into account within that patch layer and then also reconsidered in the lower patch layers.

As an example, assume you the following three hotfixes:

Hotfix #1 modifies Foo() and Bar() in SYP and Bar() in GLP-CONS (Bar() exists in GLS-CONS and thus a GLP-CONS is required to address the overlayering condition)
Hotfix #2 modifies Bar() and Baz() in GLP-CONS
Hotfix #3 modifies Baz() and Qux() in SYP
Hotfix #4 modifies Foo() in SYP

Although the change in Hotfix #4 is limited to Foo() in SYP it needs to pull in Bar(), Baz(), and Qux() for SYP along with Bar() and Baz() for GLP-CONS. Hotfix #4 will pull in the encompassed fix to Foo() for Hotfix #1 which includes a dependency on Bar() but also contains a GLP-CONS version of Bar(). That GLP-CONS version of Bar() is then evaluated and the dependency it has on Baz() (from Hotfix #2) is pulled in. Because Baz() overlayers a similar object in the SYP layer the SYP version of Baz() must also be included. Finally, as a result of Hotfix #3, a dependency exists between Baz() and Qux() so Qux() is also ultimately pulled in.

I hope this provides better insight into how we calculate application dependencies and why certain hotfixes may contain more application elements than what was directly modified by the actual hotfix change!




Источник: http://blogs.technet.com/b/dynamicsa...-hotfixes.aspx