Gracefully handle mismatched msvsmon (remote debugging tools) version
Mismatched major versions (VS 2015, VS 2017, etc.) of msvsmon (remote debugging tools) running on a deployment or debug-target machine and the version of Visual Studio connecting and attaching as the debugger don't work entirely. Slightly mismatched (minor version differences) between the two will often work, but intermittently crash.
This is a major pain point for our entire development team for a number of reasons.
A. Finding and installing the proper version of debugging tools on the client machine is unnecessarily time consuming. Most of our team isn't even aware of these versioning issues but is affected by crashes during debugging as a result.
B. VS crashes are always a hit to productivity, but also because some defect reproduction can be time consuming and difficult only to lose it mid-debugging session, as well as because the start-up performance of Visual Studio leaves a lot to be desired.
C. Further, when VS automatically restarts after a crash, it does so in a safe mode where all the UX looks broken and any environment variables present in the former session are lost (which breaks our solution file, as it relies on environment variables rather than absolute paths to vcxproj files).
D. Our engineering system automatically deploys new versions of Visual Studio automatically as they're released, but we have no such mechanism to upgrade the remote debugging tools everywhere. Even if we could, there isn't an obvious "best version" of Remote Debugging Tools that should be installed because a given machine may need to be debugged by various team members each on different versions of VS.
There are at least a couple ways this feedback could be addressed.
1. One idea is that msvsmon should become a click-once application so it is always kept up to date. Similarly, the component within VS that needs to be version-matched could also auto-update, thus ensuring they're always version-matched.
2. Another idea is that VS and msvsmon could communicate version information to one another and (a) one or both utilities could maintain backwards compatibility or (b) at the very least a warning could be presented to the user when there is a version mismatch so they're at least aware of the issue.