VS 2013 Merge Conflicts on DLL – The document xx.dll is already open

Well, right after I Tweeted how much I liked the Merge Conflict resolution built into Visual Studio 2013

<blockquoteclass="twitter-tweet" lang="en">

… I ran into a weird problem.

Note: I am using Git for the repository.

This showed up at the top of the Team Explorer window:

This is the result of running the Package Manager Console (from the PowerShell module) command


on the entire solution on two branches separately, and then merging one to the other.

That was probably not a brilliant idea, but the damage was done.

The only thing that I think might be different about these files is that the version might be a little different. So, yes, they are different files, but with the same name. The "The file has been renamed differently" message is not correct.

Here's the weird part. Whenever I select either the first entry in the dropdown list box, or the second entry, and then click Merge, I get this message box:

This message box doesn't do anything that I can tell.

If I click Yes, it dismisses the message box, but the merge conflict stays.

If I click No, it dismisses the message box, but the merge conflict stays.

Attempt to fix #1

My first reaction was to shut down Visual Studio entirely and restart it.

This did not help. Visual Studio Team Explorer reported that a merge was in progress (correct), but listed the same unresolved conflicts, and exhibited exactly the same behavior. Choosing Yes or No does not help resolve the conflict.

Attempt #2

Time to Bing it. http://www.bing.com/search?q=merge+conflict+document+is+already+open+close

Nothing on the first page that looks helpful.

The Bing alternative: https://www.google.com/#q=merge+conflict+document+is+already+open+close

Nothing about my message box.

Maybe a little more specific phrasing will help:





Attempt #3

Let's close Visual Studio, destroy the temp files, restart it, and see what happens.

What happens is that the problem remains, only the temporary file name is a little different.

Attempt #4

More Binging.


No, because these are issues about people actually renaming files. I didn't do that, although I understand that Nuget does use different paths for different versions of downloaded packages, and that is probably the basic cause behind the false rename issue.





Attempt #5

Rather than use Visual Studio, I'm going to try the Git GUI and perhaps Git BASH to resolve the conflicts.

The GUI doesn't help – it just tells me that the files are in a merge conflict, but doesn't include a way to select one branch over the other.

The BASH should help. The command is

git mergetool


Yeah. Looks like my Git configuration doesn't recognize WinMerge. Yet.

Using a little from here to make the gitconfig changes (found from http://www.bing.com/search?q=git+mergetool+winmerge):


After a little trial and error (the SO answer has a small technical problem.

The instruction to create the wmerge.sh file should have the contents in two lines.

Instead of this:

echo Launching WinMerge: $1 $2 "C:/Program Files (x86)/WinMerge/WinMergeU.exe" -e -u -dl "Original" -dr "Modified" "$1" "$2"

It should be this:

echo Launching WinMerge: $1 $2

"C:/Program Files (x86)/WinMerge/WinMergeU.exe" -e -u -dl "Original" -dr "Modified" "$1" "$2"

But SO doesn't let me make a single-character edit, and I don't feel inclined to edit the rest of the solution.

After I made WinMerge the default merge tool for Git, I used the mergetool command to resolve all the conflicts. Mostly, Git thought the files were deleted, and so I just accepted the deleted version. I'm not entirely sure where this leaves my solutions and projects, but I'm sure I can always do another Update-Package command for Nuget.

And THAT solved the problem.



comments powered by Disqus