Common Azure DevOps Pipeline Issues After Upgrading Dynamics 365 F&O
After upgrading Dynamics 365 Finance & Operations, it is very common that the build pipeline starts failing even when no code has changed. In most real projects, the root causes are related to platform version mismatch, metadata backup behavior, and test framework binding issues.
This article summarizes three real-world issues and their practical fixes.
1. AXModulesBuild.proj – Failed to generate project files
Error message:
AXModulesBuild.proj(28,5): Error : Failed to generate project files. Please check GenerateProjErrors.log in the additional logs for details.
When opening GenerateProjErrors.log, you will usually see that the platform version on the build machine does not match the metadata/package version.
Real scenario
| Component | Version |
|---|---|
| Build VM | Platform 44 |
| Metadata / Package | Platform 45 |
The build VM is on a lower platform version than the package → project generation fails.
Fix
- Update the Build VM to the same (or higher) platform version as the metadata.
- Clean old metadata:
Remove-Item J:\AOSService\PackagesLocalDirectory\* -Recurse -Force
- Restart the VM.
- Run the pipeline again.
There is no safe workaround for this issue. The platform versions must match.
2. RoboCopy backup takes too long after upgrade
After an upgrade, the RoboCopy step often copies the entire metadata again, which can take 20–40 minutes on a DEV build VM.
This happens because the existing backup was created from a different platform version, so RoboCopy cannot detect matching files.
Fix: Use multi-threaded RoboCopy
robocopy $source $dest /MIR /MT:16 /R:2 /W:5
Explanation
| Flag | Description |
|---|---|
| /MT:16 | Enable 16 parallel threads |
| /R:2 | Retry 2 times on failure |
| /W:5 | Wait 5 seconds between retries |
This typically reduces copy time from ~30 minutes to 5–10 minutes.
Best practice
- Recreate the metadata backup after each platform upgrade
- Do not reuse backups from older versions
3. TestStart.ps1 – Assembly binding redirect failure
After upgrading, test execution may fail due to assembly version mismatch. The binding redirect in TestStart.ps1 must be updated.
Fix
$bindingRedirect.SetAttribute("oldVersion", $OldVersion)
$bindingRedirect.SetAttribute("newVersion", $NewVersion)
Instead of hard-coding the version, use dynamic variables:
- $OldVersion → previous assembly version
- $NewVersion → current platform assembly version
This ensures the test framework loads the correct DLL after the upgrade.
Recommended Post-Upgrade Checklist
On the Build VM
- Update the VM to the correct platform version
- Clean PackagesLocalDirectory
- Restart the VM
- Recreate metadata backup
In the Pipeline
- Use multi-threaded RoboCopy (/MT)
- Avoid using backups from older platform versions
- Update TestStart.ps1 binding redirect
Summary
| Issue | Root cause | Quick fix |
|---|---|---|
| AXModulesBuild.proj failed | Build VM platform lower than metadata | Upgrade Build VM to matching platform |
| RoboCopy is slow | Backup from different platform version | Use /MT or recreate backup |
| TestStart.ps1 failed | Assembly version mismatch | Use dynamic binding redirect |
In real projects, following the correct sequence will prevent most pipeline failures:
- Update Build VM
- Clean metadata
- Recreate backup
- Run a full pipeline build
Doing this properly can eliminate up to 90% of post-upgrade pipeline issues.
0 Comments