Personalized Community is here!
Quickly customize your community to find the content you seek.
Now Available in Community - New TechTalk Videos for 2020
Read More about New TechTalks for 2020
2020 Release Wave 2Discover the latest updates and new features to Dynamics 365 planned through March 2021.
Release overview guides and videos Release Plan | Preview 2020 Release Wave 2 TimelineWatch the 2020 Release Wave 1 virtual launch event
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 TechTalks | Customer Engagement TechTalks | Upcoming 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