views:

247

answers:

2

Please stick with me, this is a strange one.

Since upgrading from VS2008 to VS2010, some guys at work (and myself) found that we could no longer debug into our code. None of our breakpoints were being hit.

Without giving too much away, my work consists of writing .NET apps which run on top of a custom platform application we’ve developed. These apps are compiled to .NET 2.0. Debugging typically involves setting our platform app's exe as the startup program to debug into, and launching from there.

Interestingly, none of our developers working on Vista/Windows 7 machines had any issue – just the Windows 2003/XP crowd.

Something about the combination of Visual Studio 2010, .NET 2.0, and Windows XP meant that we could no longer debug into our applications.

I have absolutely no idea why this issue should arise only in Windows 2003 and XP machines. Can anyone shed any light?

+1  A: 

Try deleting the user option files for the projects and solution. Delete all obj and bin folders. More importantly, clear out the temporary files.

Using Visual Studio 2008 temporary files, for example:

  • ("%APPDATA%") & "\Microsoft\VisualStudio\9.0\ProjectAssemblies")
  • ("%USERPROFILE%") & "\Local Settings\Application Data\ApplicationHistory")
  • ("%USERPROFILE%") & "\Local Settings\Application Data\Microsoft\VisualStudio\9.0\ProjectAssemblies")
  • ("%WINDIR%") & "\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files")

Real Life Example

I was debugging the Coding4Fun's Searching the Desktop VB.NET code at http://blogs.msdn.com/b/coding4fun/archive/2007/01/05/1417884.aspx. I noticed that on some source code files, the Navigation Bar was missing. Moreover, on the Editor's context menu the "Go To Definition" menu item was disabled. I closed Visual Studio, deleted the solution .suo file and all project .user files, re-opened the solution, and everything was back to normal.

AMissico
I haven't had a chance to try this out yet, so apologies for that. I'll try it as soon as I can. But just out of interest, why would this affect my ability to debug into the code?
TeeBasins
Clearing out the obj and bin folders removes any pdb files which hold debugging information. This would be the next step if deleting the suo does not solve the debugging behavior. This is the same as "cleaning the solution".
AMissico
Removing Visual Studio's temporary files usually fixes reference problems. For instance, a breakpoint might not be hit because is using a different version of an assembly, which is stored in these temporary folders. This is more common with C# code in Web Site projects.
AMissico
Your user debug configuration, such as breakpoints and other debug settings, are stored in the suo file. This file can get corrupted. If you have weird debugging behavior, deleting this file usually solves the problem.
AMissico
Thanks for the suggestion (and explanation). Unfortunately this didn't seem to resolve my original issue. I'll bear it in mind in the future though. Cheers.
TeeBasins
+1  A: 

I've managed to find a workaround, thanks to this post. The issue seems to be that when debugging into code which is invoked from a native exe, Visual Studio will assume you’re debugging in .NET 4.0. Subsequently all your .NET 2.0 code will run, but the debugger won’t hit any of your breakpoints.

The fix is to give the debugger a helpful hint, in the form of a .exe.config file in the directory you’re launching your startup exe from. Something along the lines of:

<xml version="1.0">
<configuration>
  <startup>
    <supportedRuntime version="v2.0.xxxx" />
  </startup>
</configuration>

This works as a fix, but doesn't actually answer why this happened in the first place.

TeeBasins