Debugging MC++ apps from VC2002 with VS2005 came up in the comments here. In the ideal world, Whidbey works great and everybody is upgraded to Whidbey (VS2005) and so nobody is still interested in VC2002. In our broken and fallen world, these ideals are not always true and so this becomes a pertinent question for some.
You have a few options, depending on your needs. The key dials to determine what’s best for you are:
A) Are you managed-only vs. Interop-debugging?
B) What .Net version is the app binding against? An app written for .Net 1.1 (such as with VS2002) can be forced to bind against .Net 2.0. Debugging cares about what version the app actually binds to; and not what version it was originally written for. See managed-debugging versioning for more details.
With those answers, the possible options are:
1) You can always use VS2002 to debug VC2002 projects. This works for both managed and interop (mixed) debugging. The downside of using VS2002 is that you don’t get the new .Net 2.0 / VS2005 features; and Interop-debugging in .Net 1.1 had a lot of problems.
In general, new debuggers can debug output from older compilers. VS2005 (which targets .NET 2.0) can debug .Net 1.x apps, for managed-only debugging. VS2005 has a restriction where it won’t do interop-debugging on .Net 1.1 apps. So this gives a few options for using VS2005:
2) Bind against 1.x, and use VS2005 as a managed-only debugger. This takes advantage of VS’s backwards compat debugging.
3) Bind against 2.0, and use VS2005 in its full glory (includes interop-debugging and stability improvements and new features). Note that the app can be compiled for 1.1, and then bind against 2.0 at runtime (although that’s not guaranteed to work in 100% of scenarios). This does not require recompiling. This happens naturally when a 2.0 app loads a dll compiled against 1.1, because there can only be 1 version of those runtimes in process.