Compartir a través de

VS 2003 can not debug .NET 2.0 apps.

  • Artículo

Somebody asked here on the forums if you can use VS 2003 to debug .NET 2.0 (whidbey) apps. Unfortunately, the answer is no.
VS 2003 can not debug .NET 2.0 apps.  It is a restriction in the underlying .NET debugging services (see below)
You can still use the .NET 2.0 SDK tools (such as Mdbg, DbgClr) to debug .NET 2.0 apps.  However, Visual Studio 2005 is bar far the best tool to be using for .NET 2.0 apps.
 

Backwards is easier than forwards:
Now VS 2005 can debug existing .NET 1.0, 1.1 apps. It's much easier to go backwards than forwards. In fact, there is technically nothing the CLR can do stop VS from doing this (not that we would want to) because in a worst case, VS 2005 could have both a VS2005 and VS2003 debug engine. However we did try to make this much easier by keeping ICorDebug relatively intact from 2003 to 2005.

Last I checked, the VS2005 project system only wants to build .NET 2.0 apps. (It will try to convert 2003 projects to 2005 projects).  (update:) See John Rivard's explanation for why VS only targets its matching CLR.

Why?
In general, debuggers can't do source level debugging on new compilers because the debuggers usually need intimate information that change with the new compilers. For the CLR, future CLRs can add radically new concepts that confuse older CLRs. For eg,  .NET 2.0 has generics and discontinuous methods, which would confuse a debugger targeting .Net 1.0.  Another more general example is that the new compilers can revise the PDB formats, and then the old debuggers are broken.  (Matt Pietrek elaborates on this further here)

At about this point, somebody always has to mention that you can take a native debugger from 15 years ago and attach it to an app compiled today. That's true, but you'll be debugging at the assembly level - and issue here is debugging source  level. That same 15 year old debugger could also debug a .NET 2.0 app ... at the assembly level.

See CreateDebuggingInterfaceFromVersion() for more on the technical details about the CLR Debugging services versioning.

Comments

  • Anonymous
    December 02, 2005
    I have not expected that VS2003 can debug 2005 programs... but yes, I expect the viceversa.
    I am used with this from Word - each version of word can open "younger" created docs - but not oldest.
    And for a reason ... usually you can not know very well the future - but it easier to know the past

  • Anonymous
    February 09, 2006
    My old Java IDEs work with my newer JAVA SDKs. I would expect the Visual Studio 2003 to be able to compile .Net 2.0 code and the Object process should be able to parse 2.0's classes using the System.Reflection class.

  • Anonymous
    February 09, 2006
    Matt - that's a noble goal, and it would be nice if VS worked that way.
    Regarding Reflection: there are some inate limitations to your proposal. How would you express a V2.0 Generic type through V1.1's reflection? (which does not know about generics).
    Solutions usually fall into 2 camps:
    1) "type erasure": Basically, all V2 types would look like V1 types. This means you couldn't instantiate a generic type across libraries.
    2) shoehorn v2 to look like v1 as much as possible. Hwoever, even if the API signatures stay the same, there will almost always be some broken semantics / invariant. If you push a tool in the right way, the tool will hit that and explode. For example, a non-generics-aware V1 tool may get confused when it sees the same method compiled two different ways.

  • Anonymous
    July 24, 2006
    I received some questions in the mailbag about what Debugger.Launch actually does. Debugger.Launch the...

  • Anonymous
    April 20, 2007
    "Which versions of a managed debugger (eg, Visual Studio) can debug which versions of the CLR? And How?"

  • Anonymous
    July 05, 2007
    I've had enough "Debugger + Versioning" posts to go back and create a versioning category