Q1: What is a kernel hotfix?
A kernel hotfix updates the binary source files and other supporting files for all the AX components.
Kernel hotfixes are therefore also commonly referred to as binary hotfixes. Some examples of the files a kernel fix may update are the executable files (ax32.exe, ax32serv.exe) and assemblies (Microsoft.Dynamics.AX.*.dll). The installer will replace each file that needs patching with a newer version.
Q2: What is an application hotfix?
An application (X++) fix updates objects in the AOT.
It can make updates in the SYP, GLP, FPP & SLP layers (the layers reserved for Microsoft code). These changes are made in the AX model store in AX 2012 and later versions.
Q3: What are the major differences between these two types of fix?
A kernel fix is always cumulative.
Each, new kernel build contains every kernel fix previously published.
An application fix is NOT cumulative.
Application fixes will normally update just the objects that need fixing in order to resolve a specific issue. However, it may also need to update any dependencies (i.e. additional objects in the AOT that the “fixed”objects reference and that have also been fixed themselves).
The exception is a cumulative update or service pack, where both the kernel and application patches are cumulative.
Q4: What is the relationship between the application code and the kernel?
The AX kernel provides the underlying functionality that supports the execution of the application (X++) code.
The X++ application code is an interpreted language and the X++ interpreter is a part of the AX kernel. The kernel manages the resources used during the execution of X++ and performs garbage collection to clean up X++ objects and other resources that go out of scope.
The AX kernel is primarily programmed in C++ but also includes .NET assemblies. It is Microsoft-proprietary code and is not published externally, whereas the X++ source code is visible in the AOT.
The X++ programming language includes system classes, which are actually kernel classes (i.e. they are implemented in C++). For more information, refer to http://msdn.microsoft.com/en-us/library/aa853470.aspx
Q5: What is a hybrid fix?
A hybrid fix includes patches for both the kernel and application code.
It’s similar to a cumulative update/rollup except that the application part of a hybrid fix will target a specific issue and is therefore not cumulative. Another similarity with a cumulative update is that you can apply just the kernel or just the application update.
Hybrid fixes are released when changes in the application code reference new functionality in the kernel (or vice-versa). However, these references are implemented in such a way as to ensure that the application will still run normally when only the application or kernel portion of the fix is installed (see Q8 for more on this).
Q6: Do I need to update my customizations after applying a kernel hotfix?
No, you do not need to resolve code conflicts between the patched Microsoft code and custom application code.
It’s a common misconception that applying the kernel hotfix will cause conflicts with custom X++ code. This only applies to application fixes, which as mentioned above will update the X++ source code in the lower, Microsoft-owned layers and can therefore affect customizations in higher layers.
Q7: Do I need to test a kernel hotfix before I implement it in Production?
You should always follow your normal processes for testing changes to your Dynamics AX environment before introducing the kernel hotfix into Production.
Each fix is tested before release, but it doesn’t completely guarantee against the introduction of undesired behaviour in a customer’s environment; every environment is different with a unique combination of hardware, configuration settings, integrations and custom application code and it’s simply not possible to test every combination before the hotfix is published.
You should always take appropriate measures that minimize the risk of downtime and ensure your business critical functionality works as expected after the fix is applied.
For more information on how to implement a Dynamics AX hotfix, please refer to the following TechNet article:
http://technet.microsoft.com/en-us/library/hh335183.aspx
Q8: Is it supported to have a different kernel and application build?
YES, it is supported to have different builds for the application and the kernel BUT… they must be for the same version and service pack level.
Our Product Group ensure that dependencies between the application and kernel are not introduced when creating AX hotfixes. Dependencies between the application and kernel builds can only be introduced in a new product version and a new service pack (NOT in a rollup/cumulative update).
We also recommend having a kernel build that is the same or higher build than the application build. Applying a kernel update is normally a simpler process than updating the application code, so in the case of applying a cumulative update it makes sense to apply the kernel part of the update as well as the application part. This also ensures that you get the full benefit from any hybrid fixes, which as mentioned above require updates in both the kernel and application to function fully.
for more information Click here
A kernel hotfix updates the binary source files and other supporting files for all the AX components.
Kernel hotfixes are therefore also commonly referred to as binary hotfixes. Some examples of the files a kernel fix may update are the executable files (ax32.exe, ax32serv.exe) and assemblies (Microsoft.Dynamics.AX.*.dll). The installer will replace each file that needs patching with a newer version.
Q2: What is an application hotfix?
An application (X++) fix updates objects in the AOT.
It can make updates in the SYP, GLP, FPP & SLP layers (the layers reserved for Microsoft code). These changes are made in the AX model store in AX 2012 and later versions.
Q3: What are the major differences between these two types of fix?
A kernel fix is always cumulative.
Each, new kernel build contains every kernel fix previously published.
An application fix is NOT cumulative.
Application fixes will normally update just the objects that need fixing in order to resolve a specific issue. However, it may also need to update any dependencies (i.e. additional objects in the AOT that the “fixed”objects reference and that have also been fixed themselves).
The exception is a cumulative update or service pack, where both the kernel and application patches are cumulative.
Q4: What is the relationship between the application code and the kernel?
The AX kernel provides the underlying functionality that supports the execution of the application (X++) code.
The X++ application code is an interpreted language and the X++ interpreter is a part of the AX kernel. The kernel manages the resources used during the execution of X++ and performs garbage collection to clean up X++ objects and other resources that go out of scope.
The AX kernel is primarily programmed in C++ but also includes .NET assemblies. It is Microsoft-proprietary code and is not published externally, whereas the X++ source code is visible in the AOT.
The X++ programming language includes system classes, which are actually kernel classes (i.e. they are implemented in C++). For more information, refer to http://msdn.microsoft.com/en-us/library/aa853470.aspx
Q5: What is a hybrid fix?
A hybrid fix includes patches for both the kernel and application code.
It’s similar to a cumulative update/rollup except that the application part of a hybrid fix will target a specific issue and is therefore not cumulative. Another similarity with a cumulative update is that you can apply just the kernel or just the application update.
Hybrid fixes are released when changes in the application code reference new functionality in the kernel (or vice-versa). However, these references are implemented in such a way as to ensure that the application will still run normally when only the application or kernel portion of the fix is installed (see Q8 for more on this).
Q6: Do I need to update my customizations after applying a kernel hotfix?
No, you do not need to resolve code conflicts between the patched Microsoft code and custom application code.
It’s a common misconception that applying the kernel hotfix will cause conflicts with custom X++ code. This only applies to application fixes, which as mentioned above will update the X++ source code in the lower, Microsoft-owned layers and can therefore affect customizations in higher layers.
Q7: Do I need to test a kernel hotfix before I implement it in Production?
You should always follow your normal processes for testing changes to your Dynamics AX environment before introducing the kernel hotfix into Production.
Each fix is tested before release, but it doesn’t completely guarantee against the introduction of undesired behaviour in a customer’s environment; every environment is different with a unique combination of hardware, configuration settings, integrations and custom application code and it’s simply not possible to test every combination before the hotfix is published.
You should always take appropriate measures that minimize the risk of downtime and ensure your business critical functionality works as expected after the fix is applied.
For more information on how to implement a Dynamics AX hotfix, please refer to the following TechNet article:
http://technet.microsoft.com/en-us/library/hh335183.aspx
Q8: Is it supported to have a different kernel and application build?
YES, it is supported to have different builds for the application and the kernel BUT… they must be for the same version and service pack level.
Our Product Group ensure that dependencies between the application and kernel are not introduced when creating AX hotfixes. Dependencies between the application and kernel builds can only be introduced in a new product version and a new service pack (NOT in a rollup/cumulative update).
We also recommend having a kernel build that is the same or higher build than the application build. Applying a kernel update is normally a simpler process than updating the application code, so in the case of applying a cumulative update it makes sense to apply the kernel part of the update as well as the application part. This also ensures that you get the full benefit from any hybrid fixes, which as mentioned above require updates in both the kernel and application to function fully.
for more information Click here
No comments:
Post a Comment