Microsoft Dynamics 365 / Power Platform - page 2
There’s a lot of change that has come with AX7 (Dynamics 365 for Finance and Operations), ranging from plentiful technical changes but also the way implementations are being run. Any large change is usually disruptive to existing users of the product, and it takes time to learn the changes and get used to them. There’s been plenty of changes in some major releases of AX, but one type of change has now come around that we haven’t had to deal with before: rethinking how we design customizations.
Even though I work on the product side these days and am crazy busy, I keep a close eye on the community out there. I have RSS feeds going for many blogs, I scan LinkedIn, I watch our insider Yammer groups, and I even follow an RSS feed of the official Community forum showing me all posts for AX/365 (yeah this is a lot but I scan through the titles quickly for specific things).
Ok, I’ll preface this by saying I’m very much aware that the standard X++ code in platform and application has this issue too. Thanks for letting me know :-) But as the saying goes: do as I say - not as I do…
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.