Udostępnij za pośrednictwem

Understanding Application Dependencies in Dynamics AX 2009 Hotfixes

  • Artykuł

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!

Comments

  • Anonymous
    May 11, 2011
    Reading slowly to follow your chain of thought. :-) Next time you could try add some graphics, but thanks for posting.

  • Anonymous
    May 12, 2011
    This sounds nice in theory, but often a few lines fix generates a hotfix package which is almost as big as the whole rolup, making us spending ages on merging the layers. Needless to say, customers do not like to pay for that.

  • Anonymous
    April 10, 2014
    最近Hotfixに関する御質問を頂くことが多いですので、以下にAX2012R2のカーネルHotfix及びアプリケーションHotfixに関して、よく頂くご質問の回答を致します。

    < カーネルHotfix>

  • Anonymous
    August 22, 2014
    Innovation vs. Disruption
    One common challenge we are facing with large Dynamics AX implementation

  • Anonymous
    September 18, 2014
    The comment has been removed