New resources available on Microsoft Learn
Did you know that Microsoft Learn offers free training modules to assist you on your path to mastering Dynamics 365 for Finance and Operations? Become an expert at your own pace or share with your team to foster growth.
Dynamics 365 2019 release wave 2 plan Discover the latest updates to Dynamics 365.Release Plan | Weekly Deployment Notes
Ace your Dynamics 365 deployment with packaged services delivered by expert consultants.Explore service offerings
Connect with the ISV success team on the latest roadmap, developer tool for AppSource certification, and ISV community engagements.
ISV self-service portal
The FastTrack program is designed to help you accelerate your Dynamics 365 deployment with confidence.
FastTrack Program | Finance and Operations TechTalks | Customer Engagement TechTalks | Talent TechTalks
This is somewhat of an advanced topic for those who are willing to customize the default build definition that is created in Azure DevOps when you deploy a Finance and Operations build environment.
This topic can be useful in different scenarios, one of them is when you want to create a build process that saves time by skipping X++ hotfixes. When you check-in X++ hotfixes to your version control system, a full build will include Microsoft-owned models like “Foundation”, “Directory” and others. Building these models is necessary for full builds. However, you can create a new (partial) build definition in Azure DevOps (aka VSTS) by duplicating the existing one. The new build definition can be customized to not include Microsoft models and will be run when building the Microsoft models is not necessary (because you don’t necessarily take new hotfixes all the time). Keep in mind that the concept of X++ hotfixes does not exist as of version 8.1, which makes this article more relevant for version 8.0 and earlier.
The build automation process provides you with the capability of defining exactly what packages to build and in what order. This is not an officially documented feature.
The build definition has a variable named DependencyXml. This is the name of an XML file that you can place in the \Projects folder in VSTS. This file specifies the X++/metadata packages you are building as well as your C# projects. It also allows you to specify the order in which assemblies/packages are built. There are only a few entries to worry about. There’s an entry for any non-X++ project (like C# libraries you’re also building) and then the X++ metadata ones. This allows you to also specify the order of building. For C#, if you specify the references and referencedby correctly then it also makes sure the C# assembly is copied to the correct place(s).
Place the XML file in the \Projects folder in VSTS, and then give the dependency variable of the build definition the xml filename, for example “MyDependenciesForBuild.xml”.
Here’s an example file:
<?xml version="1.0" encoding="utf-8"?>
To show you how this maps to the actual code, here’s what it looks like in source control
I meant to say remove the first XML tag line in the example Robert provided.
Remove the starting line  and specific SkipSourcePackageGeneration set value to 1 to skip the generation of source files.
Business Applications communities