[asp.net-mvc] Visual Studio breakpoints not being hit

I'm working with an ASP.NET MVC project that seems to be having some issues when attaching to the IIS process (w3wp.exe). I'm running the solution and IIS 8.5 on my own local machine so I wouldn't think that this has anything to do with our network. What's strange to me is that I'm able to hit the breakpoints on any other solution I debug locally.

The issue I'm having exactly is that the breakpoints turn to red, hollow circles and never get hit. Usually the fix for this is a Clean/Rebuild of the solution but this hasn't worked. I've confirmed the code is being updated by adding "throw new Exception" to a page and ensuring it shows the exception. Again, this problem is only happening with this one solution. Any other solution I run the debugger with works fine. I've also tried restarting the app pool, the website, IIS, and also my computer.

A few of the articles I read mentioned that anti-virus programs can block a remote debugger from accessing the process. However, the entire setup is contained on my local machine so it doesn't sound like that would be the issue. It does concern me a bit though because we recently hired a new IT guy that's been making a lot of changes to everyone's machine.

One other point to add that's unique about this web application is the binding in IIS. The binding is "*" in order to leverage some custom functionality related to subdomains.

In the meantime, I'll continue to look for a solution but if anybody has any ideas what may be causing this one solution to not debug properly I'd really appreciate it.

EDIT: Found a solution that suggested deleting the ASP.NET temporary files. No luck.

I know this is not the OPs issue, but I had this happen on a project. The solution had multiple MVC projects and the wrong project was set as startup.

I had also set the configuration of the project(s) to just start process/debugger and not open a new browser window.

So on the surface it looks as if the debugger is starting up, but it does so for the wrong process. So check that and keep in mind that you can attach to multiple processes also.

Silly mistake that left me scratching my head for about 30 minutes.

In Visual Studio 2017 you need to make sure you're not in release configuration mode.

1. Open the build menu ddl
2. Click configuration manager
3. Change from 'release' to 'debug'

In my case I had a string of length 70kb. Compiler did not thrown any error. But Debugger failed to hit the break point. After spending 3 hours and scratching my hair I found the cause for not hitting the break point. After removing 70kb data break point worked as normal.

Right click on your project, then left click Properties, and select the Web tab.

Verify whether the correct server is selected for your case:

• IIS Local

• IIS Express

If none of the above work, double-check your code. Sometimes the reason why the breakpoint appears to not be hitting is due to the block of code containing the breakpoint is not being executed for sometimes inadvertant reasons.

For example, forgetting the "Handles Me.Load" has gotten me a few times when copying and pasting code:

    Protected Sub Page_Load(ByVal sender As Object, ByVal e As System.EventArgs)
    --this block of code will not execute
    End Sub 

vs

    Protected Sub Page_Load(ByVal sender As Object, ByVal e As System.EventArgs) Handles Me.Load
    --this block executes
    End Sub

In my case this solution is useful:

Solution: Disable the "Just My Code" option in the Debugging/General settings.

Reference: c-sharpcorner

If anyone is using Visual Studio 2017 and IIS and is trying to debug a web site project, the following worked for me:

1. Attach the web site project to IIS.
2. Add it to the solution with File -> Add -> Existing Web Site... and select the project from the inetpub/wwwroot directory.
3. Right-click on the web site project in the solution explorer and select Property Pages -> Start Options
4. Click on Specific Page and select the startup page (For service use Service.svc, for web site use Default.aspx or the custom name for the page you selected).
5. Click on Use custom server and write

http(s)://localhost/(web site name as appears in IIS)

for example: http://localhost/MyWebSite

That's it! Don't forget to make sure the web site is running on the IIS and that the web site you wish to debug is selected as the startup project (Right-click -> Set as StartUp Project).

Original post: How to Debug Your ASP.NET Projects Running Under IIS

I struggled forever trying to fix this. Finally this is what did it for me.

Select Debug->Options->Debugging->General

Tick Enable .NET Framework source stepping.

(This may be all you need to do but if you are like me, you also have to do the ones stated below. The below solution will also fix errors where your project is loading old assemblies/.pdb files despite rebuilding and cleaning.)

Select Tools -> Options -> Projects and Solutions -> Build and Run,

Untick the checkbox of "Only Build startup projects and dependencies on Run",

Select Always Build from the "On Run, when project are out of date" dropdown.

The issue was resolved by unchecking the

Properties > Build > Optimize Code

setting on the web page properties screen (under General).

It might also be (which was the case for my colleague) that you have disabled automatic loading of symbols for whichever reason.

If so, reenable it by opening Tools -> Options -> Debugging -> Symbols and move the radiobutton to "Load all modules, unless excluded"

One of my projects in my solution was set to Release mode. I changed it back to Debug mode, and the breakpoints are hitting now.

If any of your components are Strong Named (signed), then all need to be. If you, as I did, add a project and reference it from a Strong Named project/component, neglecting to sign your new component, debugging will be as if your new component is an external one and you will not be able to step into it. So make sure all your components are signed, or none.

I had the same issue in a Xamarin.Forms project. The fix was manually converting the PCL from .NET 4.6 to .NET Standard 2.0.

For Visual Studio Mac: make sure you do it for each project

Go to Visual Studio Menu:

Debug -> Attach to Process

And then click the Select button, as in the image below:

Then make sure the "Automatically determine the type of code to debug" option is selected, like this:

In my scenario, I've got an MVC app and WebAPI in one solution, and I'm using local IIS (not express).

I also set up the sites in IIS as real domains, and edited my host file so that I can type in the real domain and everything works. I also noticed 2 things:

1. The MVC code debugging was working perfectly.

2. Attaching to process worked perfectly too. Just when I was debugging it didn't hit the breakpoint in my API.

This was the solution for me:

Right click webapi project > properties > Web > Project URL

By default it points to localhost, but since I set up the site in IIS, I forgot to change the URL to the website domain (i.e. instead of locahost, it should say http://{domain-name}/).

You can't hit breakpoints while attached to IIS process if you haven't logged into your Microsoft account in VS2017.

My case is not mentioned here:
I have to run the web project on a fake domain (settup on IIS and /hosts/etc) because of the callbacks from a third party site.

I was seeing two w3wp processes in the process list of VS:
w3wp.exe User Name: IIS APPPOOL\Default app pool
w3wp.exe User Name: IIS APPPOOL.svc

I had to to manually attach to second one to be able to debug.

So I realised the app pool of my Fake domain in iis is not set to "Default app pool"

https://manage.accuwebhosting.com/knowledgebase/2532/How-to-change-application-pool-from-IIS.html

As soon as I changed the domain's app pool to the "Default app pool" visual studio started to debug the web app.

Right click on your project, then left click Properties, and select the Web tab. Debuggers > ASP.NET

Enable 'Managed Compatibility Mode'. Go to Tools->Options->Debugging and enable Managed Compatibility Mode.

In my case the actual process was different from the original started process.

Usually we bind the local-hosted services through the w3wp.exe process. In my case a custom process was used. Changing to that solved the problem.

One more thing, change from Release to Debug mode. In release mode PDB files are not getting updated with breakpoints details. So make sure you are debugging your application in Debug mode.