Finance | Project Operations, Human Resources, ...

Managing Dynamics 365 Finance source code branches: Merge not putting files in correct folders

(1) Share

Report

Posted on by jt1024

197

Hello,

A quick question about a weird merging behaviour I have not encountered before:

I have a Dev branch created from my Main branch.

In dev I'm adding two .dll's for an ISV package. These .dll's live in a //bin subfolder.

I am attempting to merge from Dev to Main and have the dll's and up in the same folders as they are in the dev branch.

In Dev the dll's in the source branch are in:

//Metadata//CCH_SureAddress//bin//SureAddressWrapper.dll

and

//Metadata//CCH_SureAddress//bin//SureTaxWrapper.dll

But... in the VM mapped to the Main branch, I select the merge from Dev, and even though Organize projects by element type option is on, after I select merge by change set the result was this:

I expected the new //bin folders to be in the CCH_* folders off the main Metadata folder, and not have a new //Metadata//Metadata//CCH_* set of folders created.

What am I doing wrong?

I have the same question (0)

All responses (4)

Answers (0)

Suggested answer

Anton Venter 20,346 Super User 2025 Season 2 on at

Like (0)

Report

Hi,

The problem is the "Metadata" in your mapping. The Metadata folder mapping should be to the packagesLocalDirectory folder. So without Metadata in the local path folder.

Was this reply helpful? Yes No
jt1024 197 on at

Like (0)

Report

Hello Anton,

I think I have it set up correctly, does this look right to you?

Was this reply helpful? Yes No
jt1024 197 on at

Like (0)

Report

I've come back to this work.

Maybe I'm doing things differently this time around but I'm having a different result.

Here's what's happening:

Then I set up the merge dialogue as follows:

This is the result I'm receiving:

I figure I'm not noticing some simple mistake I'm making.

Anyone have any advice or ideas?

Thanks so much.

Was this reply helpful? Yes No
Suggested answer

jt1024 197 on at

Like (0)

Report

I found that SureTaxWrapper.dll already existed on the target. I think this closes the case.

Was this reply helpful? Yes No