Unable to debug C# solutions

Question

I'm using Visual Studio 2005 Pro.
This problem is repeatable with archived code on backup discs as well as new solutions.


When I attempt to run my apps in Debug Configuration with breakpoints, I get the message:
the following module was built either with optimizations enabled or without debug information.

D:\Programming\Solutions\******...

To debug this module, change its project build configuration to Debug Mode. To suppress this message, disable the 'Warn if no user code on launch' debugger option.

Here's a screenshot.
This is done with a brand new solution. File > New > Project > C# > Windows/Windows Application > Ok > Build > Run.

[update]

as par this thread, I've tried restoring factor default settings.  No dice.

[update2]

If I RClick on the project in the solution explorer, and hit 'clean' or 'rebuild', then F5, I'm good and my breakpoints work.
However, as soon as I make a code change and hit F5 next, I'm back to the same behavior as before.

Answer 1

I actually know what is causing this behaviour but out of the box it shouldn't be set like this, strange. Anyway here is how to solve this one:

1. Right-mouse click the project and select "Properties"
2. Click on the "Build" tab
3. At the bottom in the "Output" section there is a button "Advanced", click on it (this will open the Advanced Build Settings dialog)
4. In that dialog there is again a "Build" section. Set the "Debug Info" to either "Full" or "PDB-only".

Answer 2

I guess I should have been more specific.
The said combo box is already set to "Full." "PDB-Only" doesn't change the behavior.
For the sake of credability, here's another screenshot.

Answer 3

You also have this for new projects you say, right? Can you create a new dummy console application and post the contents of the .csproj file?

Answer 4

Thanks for your continued help, Gabriel.

Okay, I just created a brand new C# Project.  To validate the continued behavior of my IDE, I tossed some sample code in:
-------
int i;
i = 33;
-------

I placed a breakpoint on the second statement.
Ran it.  It broke at the said statement.  Cool.

I stopped debugging, then ran it again.  This time, the breakpoint bullet became a hollow red dot, and it did't stop like it should have.

I added a third line
-------
int y = i;
-------

Ran it, it debugged correctly.  Ran it again, didn't debug at all.
So yes, this happens with "blank" projects.

Here's the csproj for the solution I just created.

LINK

Answer 5

Sorry Gabriel, it never occured to me to try a console app... I've never written one in C#.
I just tried one, and with the same code snippits as above, the behavior is still incorrect.

Here's my console app csproj:

<Project DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
  <PropertyGroup>
    <Configuration Condition=" '$(Configuration)' == '' ">Debug</Configuration>
    <Platform Condition=" '$(Platform)' == '' ">AnyCPU</Platform>
    <ProductVersion>8.0.50727</ProductVersion>
    <SchemaVersion>2.0</SchemaVersion>
    <ProjectGuid>{1BB3B4F4-9B96-40D8-A6B2-74BEB402C6E1}</ProjectGuid>
    <OutputType>Exe</OutputType>
    <AppDesignerFolder>Properties</AppDesignerFolder>
    <RootNamespace>ConsoleApplication1</RootNamespace>
    <AssemblyName>ConsoleApplication1</AssemblyName>
  </PropertyGroup>
  <PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|AnyCPU' ">
    <DebugSymbols>true</DebugSymbols>
    <DebugType>full</DebugType>
    <Optimize>false</Optimize>
    <OutputPath>bin\Debug\</OutputPath>
    <DefineConstants>DEBUG;TRACE</DefineConstants>
    <ErrorReport>prompt</ErrorReport>
    <WarningLevel>4</WarningLevel>
  </PropertyGroup>
  <PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Release|AnyCPU' ">
    <DebugType>pdbonly</DebugType>
    <Optimize>true</Optimize>
    <OutputPath>bin\Release\</OutputPath>
    <DefineConstants>TRACE</DefineConstants>
    <ErrorReport>prompt</ErrorReport>
    <WarningLevel>4</WarningLevel>
  </PropertyGroup>
  <ItemGroup>
    <Reference Include="System" />
    <Reference Include="System.Data" />
    <Reference Include="System.Xml" />
  </ItemGroup>
  <ItemGroup>
    <Compile Include="Program.cs" />
    <Compile Include="Properties\AssemblyInfo.cs" />
  </ItemGroup>
  <Import Project="$(MSBuildBinPath)\Microsoft.CSharp.targets" />
  <!-- To modify your build process, add your task inside one of the targets below and uncomment it.
       Other similar extension points exist, see Microsoft.Common.targets.
  <Target Name="BeforeBuild">
  </Target>
  <Target Name="AfterBuild">
  </Target>
  -->
</Project>

Answer 6

I don't see anything special in the .csproj file. What you can do is try each of the following:

1. Start the project then in Devenv.exe menu Debug => Windows => Modules. Right-click the ConsoleApplication.exe and choose "Load Symbols" from the list. Then specify the .pdb file in the \bin\debug\ folder assuming that it exists.
2. Perform a Rebuild between code changes, this will clean the solution first and perform a build
3. Delete the .suo file between code changes, the .suo file contains the location of the breakpoints

Answer 7

1.  I don't have "Modules" in the Debug::windows menu.
2.  `Rebuild` resolves the issue for the next subsequent build.  But I've never had to do this before until yesterdays reformat of my hard drive, and it feels clumsy and out of the way, and quickly becomes irksome and feels like it's impacting my productivity and my sanity.
3.  I'll try.

Answer 8

J Hallam wrote:

1.  I don't have "Modules" in the Debug::windows menu. 2.  `Rebuild` resolves the issue for the next subsequent build.  But I've never had to do this before until yesterdays reformat of my hard drive, and it feels clumsy and out of the way, and quickly becomes irksome and feels like it's impacting my productivity and my sanity. 3.  I'll try.

Any news?

Answer 9

Still the same situation.
I'm aggravated to the point that I'm going to have to reformat my hard drive again tonight if I can't get this solved...

Answer 10

Download and run Process Explorer and try to find out which process has the .PDB file locked after the first run:

http://www.microsoft.com/technet/sysinternals/utilities/ProcessExplorer.mspx

Answer 11

I downloaded process explorer and can't get anything intelligible from it...

Answer 12

J Hallam wrote:

I downloaded process explorer and can't get anything intelligible from it...

So when you do a find on for example ConsoleApplication1.pdb there are no process that have a handle to that file?

Answer 13

Gabriel, I think I'm getting a tad warmer here.
This is a real hack, but it seems to work.  The inherent disadvantage is that the build is a bit slow due to the extra step.

I went into properties > build events > pre build >
and added this line:

C:\PROGRA~1\MICROS~2\Common7\IDE\devenv.exe /clean Debug $(SolutionPath)

Answer 14

>>So when you do a find on for example ConsoleApplication1.pdb there are no process that have a handle to that file?

Correct

Answer 15

Well it's a long shot but here are more things you can try.

• Run the following:
• regsvr32 %windir%\Microsoft.NET\Framework\v2.0.50727\diasymreader.dll
• regsvr32 %windir%\Microsoft.NET\Framework\v2.0.50727\mscordbi.dll
• Repair or reinstall the .NET Framework 2.0

I also never asked whether or not you have installed Service Pack 1 for Visual Studio 2005?

Answer 16