Menu
I'm working with an ASP.NET solution in Visual Studio 2013 that fails to hit breakpoints. Visual Studio will successfully hit breakpoints on other solutions, and the breakpoints in this solution previously worked. But at this time they fail to work.
I'm using Visual Studio 2013 Ultimate, Update 4. This is installed on Windows 8.1, 64-bit.
This is an MVC solution that contains 3 projects: BusinessEntities, DataAccessLayer (DAL), and a Web project. Breakpoints in all of these projects fail to work. I even tried a breakpoint inside the Index ActionResult for the home controller, and that still failed to stop at the breakpoint.
In the Visual Studio ribbon, solution configuration is set to Debug. Additionally, Configuration Manager shows that all 3 of my projects have a configuration set to Debug. Restarting IIS, restarting Visual Studio, and rebooting did not fix this problem. Selecting Build > Clean Solution, Build > Rebuild, and then Debug > Start Debugging did not fix it either.
In web.config, debug is set to true in this node:
<system.web>
<compilation debug="true" targetFramework="4.0" />
There are .pdb files in the bin directories of my projects. I verified that they are getting deleted when the solution is cleaned, and recreated when it's rebuilt.
What else do I need to check? I really need to get the breakpoints working in this solution. Thanks.
========
Updates on 12/30/2014 - Below are several things that I tried, following comments from @paul.abbott.wa.us. Several comments I made are deleted and just appended here for clarity.
========
I'm starting the app via VS, and running it under IIS. The version of IIS is 8.5. When exposing the process name (via System.Diagnostics.Process.GetCurrentProcess().ProcessName), it's w3wp.
In IIS, the web application has a site name like "local.mysite", and there is a matching entry in my hosts file. The site uses the DefaultAppPool, which employs the .NET CLR version 4.0 and the Integrated Managed Pipeline Mode. The 3 applications in my solution target .NET Framework 4.
If I switch this back to IIS Express, the debugger starts working. The version of IIS changes to 8.0, and the process name is of course iisexpress. Technically I don't have to run this under IIS on my workstation, but I would prefer to do so. What have I misconfigured or overlooked in IIS that could account for the debugger failing?
Reviewing the project server settings on the Web tab of the properties page, I noticed the dropdown was set to "IIS Express". Upon toggling that to "Local IIS", I was prompted to run VS as Administrator. After doing that, I was able to alter the server to Local IIS, and hit the debugger. I checked in the change, closed VS, launched VS not running as Admin, and loaded the solution. The web project failed to load with the following message: The Web Application Project [MySiteName] is configured to use IIS. Unable to access the IIS metabase. You do not have sufficient privilege to access IIS web sites on your machine.
Eventually some sections of this site will employ Active Directory authentication. So, is the solution that I need to either run the site under IIS Express, or always run VS as Administrator if I wish to run the site under IIS? Thanks.
I found a solution to get past the error message of “The Web Application Project [MyApp] is configured to use IIS. Unable to access the IIS Metabase. You do not have sufficient privilege to access IIS web sites on your machine.” Follow the steps at this post. Error - Unable to access the IIS metabase
After granting my account access to the intetsrv\config folder, the web project properly loaded in Visual Studio without running VS as an administrator.
But now when I launch the site another alert appears: “Unable to start debugging on the web server. IIS does not list a web site that matches the launched URL. Click Help for more information.” Initially I just clicked “Create Virtual Directory” and launched again, but that same alert reappeared.
So I selected the Help button from the alert. That leads to this MSDN page, which proposes about 2 dozen things to check, with about half as many links to other articles. I'm feeling a bit like Alice in Wonderland right now, heading further down the rabbit hole.
2/3/2015 Update: My workaround while running this on the local IIS instance was to run Visual Studio as an Admin. Ultimately, we changed the app to use IIS Express, then later abandoned the app for another solution that a coworker built. That decision had nothing to do with this problem. Thanks everyone for your feedback and ideas.
3/7/2016 Update: At this time I'm unable to replicate this issue, as we no longer have the solution in the state where it was when I worked on it last year. I would be grateful if a moderator could close this question. The options for closing this don't align with my current scenario, but perhaps someone else will find the suggestions below useful if they encounter this scenario. Thank you to everyone who contributed a suggestion.
725
If a source file has changed and the source no longer matches the code you're debugging, the debugger won't set breakpoints in the code by default. Normally, this problem happens when a source file is changed, but the source code wasn't rebuilt. To fix this issue, rebuild the project.
Set breakpoints in source code To set a breakpoint in source code, click in the far left margin next to a line of code. You can also select the line and press F9, select Debug > Toggle Breakpoint, or right-click and select Breakpoint > Insert breakpoint. The breakpoint appears as a red dot in the left margin.
Make sure that:
143
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
