Breaking news from around the world
Get the Bing + MSN extension
The views and opinions expressed in this blog are those solely of the author(s) and do not necessarily reflect Microsoft’s current policy, position, or branding. For official announcements and guidance on Dynamics 365 apps and services, please visit the Microsoft Dynamics 365 Blog.
Now Available in Community - MBAS 2019 Presentation Videos
Catch the most popular sessions on demand and learn how Dynamics 365, Power BI, Power Apps, Power Automate, and Excel are powering major transformations around the globe. | View Gallery
2019 release wave 2 Discover the latest updates and new features to Dynamics 365 planned through March 2020
Release overview guides and videos Release Plan | View 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 | Talent 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