Microsoft Dynamics 365 / Power Platform - page 2
Quick note on installing hotfixes and common questions around the usage of the prepare option. As I usually like to do, let’s start with some background information.
More and more customers are seeing an error in the “Generate Packages” build step on their AX7 automated builds. The build shows as “Partially Succeeded” and the step that generates packages shows a problem. The following error is shown in the build summary:
In Dynamics 365 for Operations (affectionately known as AX7), there is a clear distinction between binary hotfixes and metadata hotfixes (in LCS shown as “binary updates” and “X++ updates”). The product also has monthly platform releases and as of this writing a twice a year application release. I wanted to take a bit of time to explain the details of each and the distinction between them.
At the 2017 Technical Conference, Microsoft announced the journey to support more customizations via extensions and will gradually remove the ability to over-layer the Application Suite, similar to what was done with the platform and foundation. This is referred to as application sealing. This effort will come in waves and as we speak there’s a lot of work being done at Microsoft to make the application more extensible - some new extension features but also a lot of refactoring, extension points, etc.
This will be quick, I promise! Many people ask about branching and I promise some day I’ll revisit my “how we do development” article to reflect my personal opinions on simple branch setups for AX7/Dynamics 365 for Operations (we really need a shorter conversational name, but I’ll wait for the community to find something good and stick with SEO for now :-)
Unfortunately Dynamics AX 2012 also introduced a concept of extensions, which I blogged about here, but it’s not quite the same thing. The extensions from AX 2012 have sort of transformed in what is now known as plug-ins. More on that in a future article.
After reviewing the new paradigms in AX 7, it’s time to put these paradigms to practice and review the current and future state of the Dynamics AX application code. To recap, a package corresponds to its own mini-modelstore, with its own layers and models. Each package roughly translates to a .NET assembly, meaning it’s a unit of compilation. It also means one cannot over-layer from one package to another. Packages can “reference” each other, exactly like other .NET assemblies can reference each other. This is needed so one package can use features of another. This concept is being put to use in the standard application code, and the ongoing effort to accomplish this split-up is commonly referred to as the “package split”.
For the fourth and final part of this design, compile, run series we’ll review the structure of the AX7 model store in light of what we’ve reviewed in Part 3 (and contrast it to AX 2012 as explained in Part 1 and Part 2). This will be a lengthy article, hang on!
This is Part 3 in my design, compile, run series. Please first read Part 1 about paradigms, and especially Part 2 on design, compile, run in AX 2012.