Cost accounting model versioning conflicts after Git branch merges

ERP Microsoft Dynamics 365
, , , , , , , ,
1

We’re hitting persistent deployment failures in our D365 F&O cost accounting implementation after merging Git branches in Azure DevOps. Our team maintains custom models in the CUS layer for cost allocation logic, and we use Azure DevOps Git for source control across three development branches.

The core issue: after merging feature branches back to main, our model.xml and descriptor.xml files end up out of sync. The build pipeline succeeds, but deployments to our sandbox fail with version mismatch errors. We’ve had to roll back twice this month.

Example descriptor conflict:

<Model>
  <Name>CostAllocationCUS</Name>
  <Version>1.2.5.0</Version>
  <Dependencies>
    <Dependency>CostAccounting 1.0.0.0</Dependency>

After merge, the dependency version doesn’t match what’s actually deployed. Has anyone solved model versioning in Git-based D365 development? We need a reliable merge strategy that keeps metadata files synchronized.

system 2

Let me synthesize the solutions here since you’re dealing with all three key problem areas.

Custom Models in CUS Layer: Your models need strict version governance. Implement a version registry (Excel, database, or wiki) that tracks which version numbers are allocated to which branches. Before any developer starts a feature branch, they reserve the next available patch version. This prevents conflicts at the source.

Azure DevOps Git Source Control: Add two pipeline stages:

  1. Pre-deployment validation (PowerShell script using Get-D365Model to check target environment versions)
  2. Post-merge verification (Git hook or pipeline task that parses model.xml/descriptor.xml and validates version sequences)

Here’s a sample validation snippet:

$installedVersion = Get-D365Model -Name "CostAllocationCUS" | Select -ExpandProperty Version
$packageVersion = [xml](Get-Content "model.xml") | Select -ExpandProperty Model.Version
if ([version]$packageVersion -le [version]$installedVersion) { throw "Version conflict" }

model.xml/descriptor.xml Sync Issues: These files should be part of your merge conflict resolution checklist. Create a merge policy in Azure DevOps that requires at least two reviewers for any PR touching model descriptor files. Additionally, implement the Git hook approach mentioned earlier-a pre-commit hook that validates version consistency across all models in the solution.

For your immediate problem, audit your current branch structure. Identify all active feature branches, document their model versions, and create a version reconciliation plan before your next merge. You may need to manually update some descriptor files to establish a clean baseline.

Longer term, consider moving to a trunk-based development model with short-lived feature branches (2-3 days max). This reduces the window for version drift. Also evaluate whether all your cost allocation customizations need to be in separate models-consolidating related functionality can reduce the dependency management overhead.

One final critical point: ensure your Azure DevOps build definition includes the ModelUtil.exe step with the -metadataPath parameter pointing to your merged metadata directory. This forces a full metadata rebuild and catches descriptor inconsistencies that might slip through XML-only validation.

This draft is based on general Microsoft Dynamics 365 knowledge. It has not been verified against your specific version and environment. Practitioners: verify the steps and share your experience below.

3

I’ve seen this exact scenario. The problem is that model.xml and descriptor.xml aren’t automatically updated during Git merges-they’re treated as regular text files. When two branches increment versions independently, Git picks one arbitrarily during conflict resolution. Your deployment engine then validates against actual assembly versions and fails. You need pre-merge validation scripts that check version consistency across dependent models before allowing the merge to complete.

4

Are you using semantic versioning for your CUS models? We enforce a strict policy: feature branches can only increment patch versions (x.x.PATCH), while main branch controls minor/major increments. This prevents two branches from claiming the same version number. Also, make sure your Azure DevOps pipeline includes a validation stage that compares model descriptor versions against the target environment’s installed versions before deployment.

5

We’re using semantic versioning but not enforcing branch-specific increment rules-that’s a gap. The validation idea makes sense too. Right now our pipeline just builds and deploys without checking installed versions first. Are you running these validations as custom PowerShell scripts in the pipeline, or is there a built-in Azure DevOps task for D365 model version checking?

nicholas_guru 6

Tested this on a D365 F&O 10.0.38 environment where adding a pre-deployment PowerShell stage using Get-D365Model eliminated branch merge version conflicts across our CUS layer models.

7

Custom PowerShell. We query the target environment’s model database using the D365 PowerShell module, extract installed versions, then compare against what’s in the deployment package. If any dependency version is lower than what’s installed, the pipeline fails early with a clear error message. It’s saved us from at least a dozen failed deployments. I can’t share the full script, but the key cmdlet is Get-D365Model piped into version comparison logic.

8

Another angle: consider using Git hooks (pre-merge or pre-commit) that parse model.xml files and flag version conflicts before they even reach the pipeline. We implemented a Python hook that reads all model descriptors in the merge target, compares versions, and blocks the merge if it detects duplicate or backward versions. It’s been running for six months with zero deployment rollbacks due to version issues. The hook runs locally on developer machines and on the build agent.

9

Don’t forget about the model descriptor cache issue. Even if your XML files are correct post-merge, Visual Studio and the build environment cache model metadata. We’ve had cases where clearing the cache (delete .vs folder and bin/obj directories) resolved phantom version conflicts that looked like merge issues but were actually stale metadata. Always do a full clean before building after a major merge.