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

Update-Package

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:

http://www.bing.com/search?q=merge+conflict+document+%22is+already+open%22+%22do+you+want+to+close+it%22

No.

https://www.google.com/#q=merge+conflict+document+%22is+already+open%22+%22do+you+want+to+close+it%22

No.

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.

http://www.bing.com/search?q=merge+%22the+file+has+been+renamed+differently+on+two+branches%22+%22same+name%22

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.

http://www.bing.com/search?q=merge+update-package+%22do+you+want+to+close+it%22

No.

http://www.bing.com/search?q=merge+update+package+%22file+has+been+renamed%22

No.

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):

http://stackoverflow.com/a/9851507/100596

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.

Author

AlanM

comments powered by Disqus