All Blog Posts
Page: 1 of 14 Next
The legacy pipeline from the build VM has its own PowerShell script that generates the packages. However, it always puts the F&O platform version into the package file name which can make it more difficult to use release pipelines or including ISV licenses into your packages since the version number changes with each update, requiring you to update your pipeline settings (and finding out the actual build number to use). Continue reading below or watch the YouTube video to learn how to swap the packaging step from the legacy pipeline with the Azure DevOps task which lets you specify your own name for the deployable package zip file. You can find the official documentation on the packaging step here.
ISV licenses for Dynamics 365 F&O can only be applied using deployable packages. There are ISV license packages that only contain a license, and there are combined packages that have both the binaries as well as the license. But now with all-in-one packages on self-service environments, you can only apply the license as part of an all-in-one package. So what are your options? Check out my YouTube video and/or read on for more details.
With the upcoming April 2021 release, support for Visual Studio 2015 will be dropped. If you’re building your code using a build VM deployed from LCS, you’re using the legacy pipeline. You will have to manually update your build pipeline tasks to use the new version. The steps are fairly simple and outlined in this official docs article. I have a quick video on YouTube to walk you through this as well. There is one little flag that could trip you up, however.
Many ISVs supply their Dynamics 365 Finance / Supply Chain solutions in a deployable package, which only contains binaries. With the current enforcement (“all-in-one package”) of a long-standing best practice to deploy all code together all the time, some customers are only now faced with figuring out how to “repackage” an ISV’s binaries into their own package. In this post I will outline a few gotchas in addition to the official documentation, for both the legacy build pipeline and the new build pipeline. You can also watch a quick overview video I made here on YouTube.
Welcome to my new site. I’ve been wanting to blog more, but include topics unrelated to Microsoft Dynamics. I wanted a place to put some of the game development stuff I do. And as I’m considering to get into some regular streaming, I want a landing place for anyone checking me out. So, here we are. I started daxmusings.codecrib.com in 2010 on blogspot aka blogger. I attached the custom domain to it at a later time, keeping the daxmusings subdomain. I’ve had stuff on www.codecrib.com on and off, never very interesting. I’ve hosted it in several different ways over the years, most recently as a GitHub Pages site with custom domain attached.
Quite a few years ago, in my previous job when I was an MVP still, I did an online webinar for the AXUG called “Putting Software Engineering back in Dynamics AX” (in 2014). Admittedly it was somewhat of a rant / soap box type of talk. I guess “food for thought” would be a more optimistic characterization. I did try to inject some humor into the otherwise ranty slides by adding some graphics. At the time we were building out our X++ development team and we were heavily vested in TFS and automation, and I was very keen on sharing our lightbulb moments and those “why did we only start doing this now” revelations.
I’ve struggled with this myself for a while during the betas of “AX7”. Sometimes, symbols aren’t loaded for your code and your breakpoints aren’t hit. It’s clear that the Dynamics 365 option “Only load symbols for your solution” has something to do with it, but still there’s strange behavior. It took me a few years at Microsoft for someone to explain the exact logic there. Since I’ve been sitting on this knowledge for a while and I’ve recently ran into some customer calls where debugging trouble was brought up, I realized it’s overdue for me to share this knowledge.
Since the AXDEVALM blog has been removed from MSDN, I will repost the agent computer name post here AS-IS, until we can get better official documentation. Original post: October 20, 2017
Since the AXDEVALM blog has been removed from MSDN, I will repost the code coverage blog post here AS-IS (other than wrong capitalization in the XML code), until we can get better official documentation. Note that after this was published, I received a mixed response from developers. For many it worked, for others this did not work at all no matter what they tried… I have not been able to spend more time on investigating why for some people this doesn’t work. Original post: March 28, 2018
Welcome to 2019, the year of the X++ developer!
Page: 1 of 14 Next