3,221
Hi
After updating a module on a local VM, build and sync works fine.
After checking in to DevOps the build step failed. "The field 'xy' on the extension 'xz' already exists. This extension cannot be applied to the base element."
Some extension where renamed, but the deleted elements where also checked in.
What can be the reason on build server? Do we have to clean up somewhere?
Thanks, Jan
Reliable and scalable infrastructure may require profound DevOps expertise especially when your business operates in highly uncertain environments. An optimal workaround is to choose a DevOps packaged service offering meeting your goal (CI/CD, infrastructure audit, server infrastructure setup etc.). You can find such options following this link.
Well, the only two explanations for those files are:
1) Backup of the PackagesLocalDirectory (can happen if you had them in that directory before first ADO build on the server)
2) Your current ADO codebase
Please check those and I'm sure you can solve it.
Which system are you now talking about? The place which you need to check is the actual code directory in ADO. Seems that your problem might be your current source code (caused by wrong/incomplete check-in from dev system), not your build server.
Remember, the build server starts from scratch (="vanilla" backup) every time. So if the backup was not bad, then those duplicates indicate that you have wrong stuff in your source control and the build actually works correctly (=fails).
Clean up of Packages directory didn't help. Found on K:\AOSService..., in Module Extensions (Forms, Tables) duplicates. Somehow they where not deleted, but correctly marked for deletion on DevOps. What can be the reason? Should they be deleted manually one by one or hole module directory?
Here's how the build server works.
1) When you do a build (from ADO pipeline) for the very first time, the server takes a backup of AOSService/PackagesLocalDirectory
2) Before each build, this backup is restored, and then the build takes latest code from ADO on top of that, and builds it
If you have ever done some own development on this server before building via ADO, those objects would be in the backup which is restored before each build. And that would explain your problem. You should use the build servers only for ADO builds, not for development, not for manual Visual Studio builds.
You should be able to remove the bad backup in J:\DynamicsBackup\Packages . Or, deploy a new build server. Or, start using a hosted build agent.
Do I understand correctly that you're using a VM as a build server and not a Microsoft-hosted agent? Don't you want to make a switch now?
#1
André Arnaud de Cal...
293,027
Super User 2025 Season 1
#2
Martin Dráb
231,852
Most Valuable Professional
#3
nmaenpaa
101,156
Moderator
Share
Report
All responses (
Answers (
