Issue: Cannot compare, diff or merge files on computers that only have Team Explorer.< xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" />
Details: Due to dependency on a DLL that is not included with Team Explorer, DiffMerge.exe fails on computers that do not have Visual Studio 2005 Team Suite or one of the Team System role-based editions.
Workaround: Install Visual Studio 2005 Team Suite, or one of the Team System role-based editions.
We are experiencing this issue however we DO have the VS 2005 Team Suite Trial Edition installed. What DLL is missing How can I verify this
Thanks,
~slee
Cannot compare, diff or merge files
turbofreddan
How about the merge tool I just had a developer lose all of his changes due to the merge tool not working correctly... please note that we DO have the VS Team System Suite Trial Edition installed.
Thanks
Christian Jacob
As an aside, if you're about to perform what you consider to be a potentially destructive operation, what some people have found to be comforting is a simple alias to shelve all their workspace's current pending changes before doing that operation. For instance, a "shelve all" alias might look like:
doskey sa=tf shelve backup /i /replace
Brachole
That said, the easiest path as a workaround with beta3 is to just configure a different diff tool, like windiff. Buck posted some instructions here:
http://blogs.msdn.com/buckh/archive/2005/11/16/493461.aspx
aytas
Assuming it's not a simple fix to get that working, you can configure a merge tool as well. During development I tested with KDiff3 (among others) to make sure things worked fine. If you were to use KDiff3, for instance, you could make your arguments string: %3 --fname %8 %2 --fname %7 %1 --fname %6 -o %4
Now, the developer losing changes because of this is another issue. Even if the external tool runs fine, we prompt the user for whether to keep the output of the command. If the tool didn't work (never started, crashed with error, whatever), the user should always be able to click No and they'll still have their file in the pre-resolve state. Can you find out whether the user got this prompt or not We try to detect whether the tool successfully started or not, but in the case of diffmerge.exe, the tool actually starts fine as diffmerge.exe can actually run fine up until it does the LoadLibrary call to try and get access to msdiff.dll, which is when things break if we can't load msdiff.dll.
In such a case, TF would see that the external tool exited and prompt the user for whether to keep the output. If the user clicks "Yes" to that, then unfortunately, yes, the changes will have been lost. We considered checking the exit code and only allowing the merge if the external process exited with exit code 0, but we found multiple merge tools that unfortunately gave non-zero exit codes even in success cases, which is why we ignore the exit code.
Grwilhelm