I am having an issue with breakpoints not being hit in Debug mode for any of the solution's microservices, regardless of whether I run them individually or as multiple startup projects alongside my web app.
I don't get any warnings whatsoever. I run the app on the browser which in turn calls the MS, but the MS responds without the breakpoint ever being hit. There is one caveat though, we added swagger on one of the MSs and through that, the breakpoints are hit as expected.
I am using VS 2022 (recently upgraded to 17.3), Dependency Injection and .net core 6.
Any ideas?
For anyone struggling with this, I managed to find a solution.
Because my MSs were running on IIS, I went through every single MS's launch settings and I set the process to IIS.
I then re-applied the solution's Multiple Startup Projects, and breakpoints are now hit as expected.
Related
I created a new ASP.NET 5 RC1 WebApp using Visual Studio 2015 and published it to Azure. I turned on remote debugging and selected VS 2015 for the debugger. I can attach to the WebApp, but any breakpoint I set is not showing up completely red. Hovering over the breakpoint gives you the message "The breakpoint will not be currently hit. No symbols have been loaded for this document." I did a bunch of searches to see if anyone else had encountered this issue. I found some articles that seemed to indicate the solution:
Remote debugging Azure website: Breakpoints not hit
Azure Website Remote Debugging with git deploy not working
I tried turning off "Just my code" and adding the app setting, but neither of these worked. I even had a colleague try the same thing from his system and his Azure account to make sure it wasn't just an environmental issue on my system. Does anyone know how to fix this?
The problem is the VS 2015 Azure tooling is not yet DNX aware at the debugger level. So for now, you'll need to manually attach the debugger, using the steps documented in this article.
Once you get the list of processes, you'll want to attach to the dnx.exe process, instead of the usual w3wp.
I just tried with a new ASP.NET RC1 app, and was able to set and hit breakpoints. It took a while to attach and load symbols, so be patient :)
I have a WCF service hosted in IIS which is consumed by a Silverlight client application. When I run the Silverlight application, none of the break points seem to get hit (not breakpoints in the service, although they also don't get hit. That service is not in the same solution).
Normally when I've created SL projects in the past, they hit break points by default, and I can't thing I've changed any of the settings.
When I run the project, I do get a message box saying, "The Silverlight project you are about to debug uses web services. Calls to the web service will fail unless the Silverlight project is hosted in and launched from the same web project as the web services. Do you want to debug anyway?"
So I say 'yes'.
My break point is in a place that I know gets hit (InitializeComponent in MainPage.xaml.cs), so that's not it.
I don't know if it makes a difference to the client application, but the WCF service does have within its App.config the compilation debug set to 'true'.
Can anyone help?
Edit:
Some useful points: The project is set to debug. There is no web component to the SL project. The application compiles and runs normally. The code in the screen shot below is the code behind for the main page which is the default page (and the one I see when I start the project). The Visual Studio version is 2010 Ultimate (version 10.0.40219.1 SPRel) and I am not creating an OOB application. As well as just running regularly, I have specifically started from the Debug->Start Debugging option in Visual Studio.
Screen shot:
If that image isn't clear enough, there is the full resolution one here.
Second screen shot showing a break point on the InitializeComponent in MainPage.xaml.cs which doesn't fire (the previous one showed the constructor of the related view model).
Again, if that's not clear enough, the full resolution version is here.
The message your getting is unrelated to your breakpoints not being hit. This 'warning' isn't entirely true as well, as long a the webservice you're calling is running you'll be fine. You can happily ignore this warning.
As to not hitting breakpoints, I can think of two reasons. You could be building in release mode, or you could be starting the wrong project. You should not be starting the MyApp.Web project Visual Studio probably created for you, but the actual Silverlight project.
If it isn't one of those options you should provide a bit more detail about what you're doing, like Visual Studio versions, whether you're running an out-of-browser app, does the app actually work etc. There can be a few more things to check but it hard to guess it them with this little info.
I'm not seeing a test page.htm in your solution. How are you hosting / running the SL app?
If you were hosting it in an ASP.NET web app I'd say check that the Silverlight debugger was enabled on the web project project properties.
But as it is I can't see how the silverlight app is getting run at all...?
I think I'm having an issue where, if I set breakpoints in a ASP Azure project, the page just freezes without letting me step around in Visual Studio 2010. I'm not sure if I have a bug, or if I'm doing something wrong.
I have a Silverlight 4 app that consumes a WCF service made available from an Azure project. If I start up VS, build, and run, everything works fine. If I set a breakpoint in the service getData() method, the browser tab becomes unresponsive. If I unset the breakpoint, it remains unresponsive until I restart visual studio.
I have the Azure project set as my web role. I am able to hit breakpoints in WebRole.cs in the ASP project, but it seems like putting a breakpoint in the .svc file messes it up.
Is this a known issue? Or could I be doing something wrong?
I don't how the Azure project might effect things but but you might want to look at:
Configuring Message Logging
Service Trace Viewer Tool (SvcTraceViewer.exe)
WCF Test Client (WcfTestClient.exe)
Somehow, since some time I'm experiencing problems with debugging my ASP.NET website.
Every time I try to debug the website ASP.NET shuts down (global.asax_Application_End is called).
I believe this is triggered because the site is built by Visual Studio. However, manually (re)build the site and then start debugging also restarts the site. Even debugging and ending the debugging session, clicking a couple of buttons on the site to get to the desired state, and start a debugging session again still triggers a build action, which causes the site to restart.
Since restarting resets HttpRuntime.Cache booting the site takes a long time, and sometimes I want to debug some situation that involves caching.
Now there is a setting on the website's property pages:
Start Action (F5):
Before running startup page:
No Build / Build Page / Build Web Site.
I've set it to No Build, restarted Visual Studio, but still it triggers the build action every time I hit F5 or the Start debugging button...
Anyone any ideas as to how to resolve this??
Thanks,
Jaap
We've solved this by converting our project to a Web Application instead of a Web Site. This had some impact on our architecture since we had some classes in app_code which we needed to use reflection on during site startup.
It turns out that the Web application in combination with "Use Custom Web Server" fixed out issue!
I have a web application that I've always been able to run in Visual Studio and it debugs just fine (breakpoints work, I can pause execution, etc). Recently, the behavior changed suddenly, and a few things happen:
I start debugging, it lauches IE and loads the application, but after a few seconds (sometimes the page hasn't even displayed yet), Visual Studio acts as if debugging has stopped - I'm able to edit code in VS again, and the "Play" button on the toolbar is enabled. The application continues to run in the IE window just spawned, but I'm not attached to it
During this few seconds that VS is "debugging", because it detaches, my breakpoints show as hollow - as if I'm set to "Release" mode and they won't be hit. In fact, I have a breakpoint set in Page_Load, and it skips right by. I've checked, and I'm set to debug mode, though the compile mode dropdown is missing from my toolbar (I checked in the build properties to ensure I was in debug mode).
Can anybody shed some light here?
It turns out that this was actually a result of an upgrade to Windows Vista. VS wasn't being "Run as an Administrator", which caused it to lack the rights to attach to other processes for debugging. As a result, debugging would stop right after it started. Changing the VS shortcut to run as an administrator resolved this problem.
I've experienced samely looking behavior. The cause was in existence of several <system.web> sections (which is allowed by web.config schema). Visual Studio debugger (versions 2008 and 2010 were tested) looks in the first encountered section only. So if your <compilation debug="true"> tag is not in the first one, it thinks that there are no compilation.debug setting present and genrally tryes to add <compilation debug="true"> to the first <system.web>. In some cases VS2008 just silently procceds in this case. For example look here: https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=510354#details"
Have you installed anything else on the server / workstation recently?
We have a third party app that doesn't allow us to debug, w3wp.exe crashes immediately upon an attempt to debug.
I ran into something similar when I had placed some code in a constructor that was crashing. Exact same issues where the Debug would disconnect just after the application started up.
The short if it, check that you haven't configured a class constructor to run during web startup that is crashing...
Quick windows 7 update: I had to add "localhost" to my list of trusted sites to correct this issue...go figure.
Just a workaround for those (like me) for whom the above solutions do not work: After starting the app you wish to debug, go to Debug -> Attach to Process, and attach it to the process you want to debug. Works on my machine.
In my case, I faced this issue with Visual Studio 2019 and 2022 as well.
I tried upgrading/downgrading Visual Studio versions but nothing helped.
On debugging, I finally found the root cause and sharing it here to help others facing the same problem.
I was using Brave browser with Visual Studio and whenever I uploaded a file in my application, the Visual Studio debugging stopped automatically. The root cause of this issue is the feature in Visual Studio to stop debugging on closing the browser. With Brave browser Visual Studio feels like we have closed the browser on uploading the file. So to fix this issue I have turned of this setting as given here.
You can find this setting here
Tools > Options > Projects and Solutions > Web Projects > Stop debugger when browser window is closed, close browser when debugging stops
Just turn it off and everything should work fine.