Darko
Darko

Reputation: 38860

When debugging ASP.NET MVC app, breakpoints are not hit

When trying to debug a ASP.NET MVC app, the breakpoints in my controllers arent getting hit. When entering debug mode they just show an empty red circle with a warning triangle instead of the normal full circle. This is strange because debugging was working fine until now, and no configuration changes have been made in my environment for a while.

I have seen this question and had a look at my modules view and the correct ones aren't being loaded, however I'm not sure how to remedy this. Also all the relevant pdb files are in the bin folder of the site.

Any suggestions on how to fix this?

Cheers!

EDIT: The app is running as a local site on IIS7 and I'm debugging with VS 2008

Upvotes: 31

Views: 54761

Answers (20)

MartyP
MartyP

Reputation: 1

My solution was basically my mistake because I had moved the project folder. My resolution was, after I moved the folder, do NOT use "Open...Open website" and then browse to your website folder. DO NOT browse to your solution .sln file and open with that. Instead, DO USE "Open...Project/Solution" then browse to your csproj file and open that. Close IIS(Express) first. Rebuild. It should run the latest copy. The .sln will mess you up every time.

Upvotes: 0

GER
GER

Reputation: 2032

I found that the Optimize code checkbox on the project properties window, Build tab, would also cause this to occur.

Uncheck this checkbox as well.

Optimize code checkbox on Build tab of Project properties

Upvotes: 0

Prashant vishwakarma
Prashant vishwakarma

Reputation: 487

Most of time when your solution has changed into debug to Release mode.

https://www.youtube.com/watch?v=Tc-EamOXAcQ

Upvotes: 0

Chidi-Nwaneto
Chidi-Nwaneto

Reputation: 654

I have read and implemented all the suggestions above, to no avail.

What worked for me is, i simply changed the controller action i was trying to break into to [HttpPost].

My issue was that i was trying to debug a method decorated with a [HttpGet] attribute routing to a different view and instead of hitting my break point, it keeps routing and displaying the return view.

Hope this helps someone!

Happy coding.

Upvotes: 0

Tom
Tom

Reputation: 423

Quick fix...

Run my project in Debug. Cleaned and rebuild solution (MVC).

Re run the UI project and the Breakpoints started working again.

Hope this will help someone.

Upvotes: 0

JohnWrensby
JohnWrensby

Reputation: 2842

I had Shelved my changes in TFS and had a breakpoint set on a shelved cs file that was not part of the solution anymore. Once I retrieved my Shelveset, everything worked.

Upvotes: 0

Muhamed Shafeeq
Muhamed Shafeeq

Reputation: 1214

Change in Visual Studio Header Release option to Debug

Upvotes: 1

Brian Ibbison
Brian Ibbison

Reputation: 51

I had the same problem. Check here: Tools->Options->Debugging

Fix by selecting Enable .Net Framework source stepping

Upvotes: 5

Bill Durksen
Bill Durksen

Reputation: 1

I had a similar problem with a simple Web API project in Visual Studio 2015. I solved the problem, after reading that the easy fix was to set the Startup Project to the correct project. Since I had another Web API project in the same solution, I guessed that the project I was debugging was mixing up which index.html to debug, so I renamed that current one to index2.html. Then setting the Project properties Web tab to Specific Page and the page text: "index2.html" solved the problem.

Upvotes: 0

Suamere
Suamere

Reputation: 6248

Some team member deleted the Debug configuration for one project (The MVC Project). Though the Solution configuration was set to "Debug / AnyCPU", if you looked in the configuration for that, the Project-Configuration for the MVC Project was set to Release, with no option for Debug, and all other projects were set as Debug appropriately.

So I added Debug back to the project configurations (Just drop-down "Add"... uncheck the box to add to solution). And viola...

Upvotes: 5

George Stocker
George Stocker

Reputation: 57877

Things to try:

  1. Clean the Solution, then rebuild it.

  2. If that doesn't work, close the solution, delete the bin and obj folders, and rebuild.

  3. If that doesn't work, restart the IDE after doing step #2.
  4. If you're debugging an ASP.NET project hosted by IIS, make sure you're attached to the correct process (w3wp.exe).

Upvotes: 4

Fka
Fka

Reputation: 6234

It might be helpful to:

  1. Close Visual Studio
  2. Stop application pool in IIS Manager
  3. Delete bin and obj folder
  4. Start appliction pool
  5. Open Visual Studio and rebuild solution

Upvotes: 0

Dan
Dan

Reputation: 1

Make sure that your compilation framework version is the same as your project's compilation framework.. I ran into this and it was because the project was being compiled as 4.5 and the compilation attrib in the web config was trying to debug it as 4.5.1.

Upvotes: 0

NightOwl888
NightOwl888

Reputation: 56859

None of these answers helped me. Some of my breakpoints were hit, and some not. But I discovered the problem in my case.

If there is a file at the exact same virtual location with the exact same name as the URL you are trying to debug, the file will be served to the browser automatically by IIS and the breakpoint will not be hit because no MVC code actually runs.

Upvotes: 3

Rik Hemsley
Rik Hemsley

Reputation: 887

Clean / rebuild didn't work for me. Restarting VS did.

VS 2012, ASP.NET MVC 3, IIS Express.

Upvotes: 0

Simon_Weaver
Simon_Weaver

Reputation: 145950

Few more possibilities:

  • If you have a client and server in your solution (lets say a WPF and WCF app) you should make sure you select 'multiple startup projects'. [this one is similar to your accepted answer, but useful if you need a client running too]

  • Release mode is selected for the project. When doing a fresh get (as I discovered today) on a new machine VS seems to like to switch to 'Release' configuration profile.

Upvotes: 11

Jimbo
Jimbo

Reputation: 22964

I had this problem today - then found out that it happened because:

  1. Visual Studio 2008 had crashed, leaving Cassini (the intrinsic development web server) running on the original port.

  2. When I reopened my project and "Started" it, it couldnt run on the original port because the old development web server was still running (which I didnt notice)

  3. The pages browsed fine, but no breakpoints got hit because the URL I was using was still pointing to the old development web server port.

Upvotes: 0

JS.
JS.

Reputation: 155

I had the same problem. Check here: Tools->Options->Debugging

Check the script check box. Run the application.

I got installation corrupt message box, so did a repair of vs 2008, and its working now.

Upvotes: 0

Darko
Darko

Reputation: 38860

Ok so after 4 hours wasted, I find that setting my web project as the startup project solves the issue! This surely must be a bug...

I hope I save someone out there half a day :)

Upvotes: 41

SirDemon
SirDemon

Reputation: 1758

The following has worked for me most of the time when I had this problem:

Find where your projects dll cache is being held (usually in ASP.NET Temprorary Files). Then close VS, do an IISRESET /stop (if you're using IIS), delete all the files in dll cache. Do an IISRESET, start VS, open your project and rebuild it.

Upvotes: 1

Related Questions