Related
I am trying to set a breakpoint in JetBrains Rider, but the debugger isn't breaking.
I know for sure the application should reach the code I'm trying to break on, as changing string literals appears in the program.
I have completely reinstalled all my JetBrains programs (wiping settings). I've also tried every answer in this thread: break point is not hitting while debugging, with no luck.
This bug doesn't occur in Visual Studio, but does occur with any project in Rider.
It also doesn't happen on my other copy of Rider that I use on my other PC.
I appreciate any help, thanks!
One more caveat: I started using Rider again after an absence, I was pressing the "play" (triangle) button rather than the button with a picture of a bug.
(D'oh!)
For .Net Framework projects:
This can happen if Rider attached the debugger to a different process than the process that IIS is using.
Open Run on Rider menu and click on "Attach to process" or ctrl+alt+F5
Type w3wp, this will find all the processes IIS is running on. If you found multiple processes you can hover on them to see which AppPool is related to that process.
Click on the process to attach debugger to it.
The breakpoint should be hit now.
And make sure you are using the URL that Rider provides you when you run your project (http://localhost:XXXX), because the URL that Rider uses might be different than the Host Name you set for your IIS.
I've found what was causing it.
As of Rider 2018.1.3, the solution you're running must be on the same disk as the copy of Rider you're using.
This issue is referenced on JetBrains support here.
You can temporarily solve this by either moving your solution to the same drive, or by reinstalling Rider.
What I did before was :
Open the solution
Set some breakpoints
Click the 'bug' button in Rider (next to the play button)
Chrome would open up automatically with an URL pointing to my services
The service would work as expected, but breakpoints would not work
Stop the service
Modify some code
Start the service
Refresh the Chrome Windows from step 4
I would see the modifications in Chrome. But no breakpoints would get hit.
Now the only thing I changed is that in after step 2 I now do a
Run --> Attach to a local process... --> w3wp
After this, I just do the same steps as before, but now the breakpoints do get hit...
Refrence
For anybody who has the same problem in Xamarin Android project.
For me the breakpoints in the android project where working, like in the main activity but not in the shared project.
How i fixed it:
Go to your android.csproj file and edit it. Search your build target and check for <EmbedAssembliesIntoApk>true</EmbedAssembliesIntoApk>
If this is true, breakpoints in additional modules are not working.
Set it to false, or even better, remove this line completely.
In relation to Jessica's answer above, it appears that opening a solution in Rider using the System absolute path (i.e. /System/Volumes/Data/Users/...) appears to act as though it's on a separate drive.
After driving myself crazy for about four hours, I created a new solution and changed the solution directory from the system path to /Users/... then copied my project to this new solution which fixed the breakpoints, and opening the project from the Rider welcome screen now shows the solution directory as a relative path (~/Users/...)
Another solution for you (or other people who come across this):
When you have "COMPlus_EnableDiagnostics": "0" in your configuration or launchSettings you won't be able to hit breakpoints either.
Cleaning and rebuilding the solution, and then removing and readding the breakpoint worked for me!
None of these solutions worked. Solutions of clearing caches through the Rider interface and stuff like that, none of them worked. None of them.
The problem: a previously working referenced project of custom code (not some external library or nuget package) broke the breakpoints. Breakpoints outside the package worked, but not in the referenced project. I was getting that "stop sign" symbol in which it couldn't resolve a method.
The only thing that worked was to completely erase all instances, and previous instances, of Rider from Application Support and Caches on my mac. After following the instructions to completely erase Rider on their website, and then reinstalled it, I was able to get the breakpoints working again. Sorry, but for some of you this may be the only thing you can do.
If you're using .NET core and IIS, make sure the Application pool has 'No Managed Code' under '.NET CLR Version' in the Basic Settings:
I had this problem too and the cause was a spurious <ContinuousIntegrationBuild>true</ContinuousIntegrationBuild> in the csproj. Removing this setting restored debugging capabilities.
In my case the breakpoint not being hit when debugging a project with IIS Express.
The issue has been solved after running Rider as administrator
Thanks to #David smith's answer here:
Can JetBrains Rider work properly with IISExpress?
I know this has been asked before but I just cannot figure this out. I believe I have covered everything that has been brought up already but I'll cover those.
I am getting this message when I try to step into a service that is a project that is currently in my solution:
I have 3 projects in my solution:
SuburbanCustPortal <-- my website
SuburbanHub <-- my serice
WebsiteLogging <-- my logging project (no significance here)
I read that I should check the following items:
Make sure that debug is on. I have this in both of my project's web.config:
Make sure they are both using the same .net version. They are both on the .net framework 4.0.
Make sure Enable Just Your Code is unchecked:
The service is pointed to a local url:
I can pull up the service in my browser without error:
This is my settings for iis:
I have restarted visual studio, the computer and removed the service and added it back.
I cannot, for the life of me, figure this out. If I have missed anything I am willing to give it a shot.
It is very important that I get this resolved so I can get this project out this weekend so any help would be greatly appreciated.
IN RESPONSE TO Sanket Shah
I do not have the option w3wp.exe:
SOMETHING I FORGOT TO MENTION
I have set debug=true in both of my projects:
<compilation targetFramework="4.0" debug="true">
<assemblies>
<add assembly="System.Data.Entity, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" />
</assemblies>
</compilation>
Also, I wanted to add that I have been able to step into my service before but since coming back to the project recently, I am not able too. I have a break point on the line that calls the service and when I try to F11 in to it, I get the above message.
IN RESPONSE TO Pawel
I have tried setting symbols the follow ways and neither allowed me to step in:
I have even tried to use the Microsoft symbols:
IN RESPONSE TO Pawel #2
ADDITION INFO
I just noticed this, I'm not sure if it is related:
ADDITIONAL INFO ABOUT DEBUG MODE
I have all projects set in debug mode:
Your solution/project/settings file(s) might be / seems like it is corrupted. If you create a new solution from scratch, adding new projects which mimic your current structure, you can try and see if debugging works properly.
If that works, gradually move the code over while keeping checking that debug keeps working.
I don't know why this doesn't work.
I have a work-around for you, which you verified in the comments: add System.Diagnostics.Debugger.Break() somewhere in your service after it starts. This should pop up some sort of exception window, with a list of Visual Studio instances open. Pick the one with your solution and click OK, and it should attach correctly to that location.
Annoying? Yes. In my experience with Visual Studio, it can be very finicky sometimes about debugging into Windows services. This is the only reliable way to do it that I know about.
In addition to other answers, you can do two things:
Close your solution, delete [solution-name].suo file, reopen solution. See if your problem still persists.
Open a command prompt as admin, cd %windir%\Microsoft.net\Framework\v4.0.30319, execute this aspnet_regiis.exe -i.
In solution, have you tried to set all assemblies (client and server) to start in debug mode rather than trying to attach it after launch ? (right click on solution in the top of Solution explorer, startup, multiple startup project, choose "start" for every assembly which is an entry point : server, client, etc).
Have you tried to run only the "server" part in debug mode (the one which is not debuggable) and call it for example with soap ui ?
You should try to see if you can run it directly and debug it without the "step in" from another process, or if it also fails to load in debugger even if started directly.
FYI, if you use IIS Express it's normal you don't see "w3wp.exe", which is for IIS. You may have a iisexpress.exe process, or in some cases aspnet_wp.exe.
Don't forget to check "show processes for all users" in Debug->Attach to process window if you choose to hook on existing process rather than doing that I was saying first.
Go to Properties of the solution select Multi statup project and select all projects with start, then debug the solution.
I can't seem to be able to debug. When I try to, I don't get any build errors, and the layout changes to debug mode, but the windows never pops up. I have an orange bar at the bottom of VS, which I think is standard, but nothing happens after that. It's not just in the project I'm working on. I have started a new WFA and tried to debug without adding any code and the same thing happens. Anybody have similar issues?
I've encountered this before. Not sure what causes it, but generally it is one of a couple of things to fix it.
make sure you are building in debug and not release
close VS, go to the project's dir and delete the obj and bin directories. Reopen in VS and rebuild.
there is an option under tools - options - build (iirc) that allows for checking if source is same as code file. However, you should see a message in output window if this is the case.
on the project properties in the build (iirc) you can throttle the pdb file from full debug symbols to no pdb at all. If you are not the only person on the project check this setting still has full pdb enabled (low probability this got changed though)
make sure you're on the right platform that you are building to (x64 vs x32)
...lots more, but a starting place...
Addendum as per comment...
So, those messages are good. It is saying there are no problems (but it sounds like you already know that :) ). I would start with the general debug options you mention. Do this on a hello world app. That way you can troubleshoot the lowest common first. Here are my settings. Try to match them and see if that works. For example, I know "ask before deleting breakpoint" is irrelevant, but "break all processes when one process breaks" is important. So, I just added them all to make it easier to troubleshoot.
ALso, make sure you are getting a red dot here like so in your code in visual studio (I've seen instances where VS won't let you put this here):
Right click on the project
Click on the properties.
go to web.
Check the Box for Enable Edit and Continue .
Hope that helps :)
This is an issue with visual studio 2012. It doesn't ALWAYS show up. I've found that if you stop your program during debugging, or if you close the console window, this will almost always trigger.
However, letting it run to completion isn't enough either, sometimes this just happens.
Also you can build your application in debug mode, go to the output, run the program, and attach to that process. :P
Amazing answers already given but they dont help in the purpose. So here is my finding, no matter if i am late in answering, but it really works for me.
Even if you are developing a web app, just go to the website properties by right-clicking the project and then you see a "Web" tab on left as i have highlighted. Then just check the box saying "Enable Edit and Continue". Thats all you need to do. it works for me!
I had a similar problem, and solution was absolutely dumb. VS was confused with two instances of Internet Explorer in “Browse with” setting. So, I set Google Chrome (any browser) as default, and then set IE as default again. It deleted the other instance of IE (only one remained) and debugging was enabled.
Hope it help!
I had a similar issue.
I added up:
using namespace std;
and this solved the problem
For me, uninstalling the Redgate's Reflector plugin that had expired fixed it. I spent more than 4 hours uninstalling, rebooting, reverting to older code, etc etc..
When my default browser was changed to CHROME, I could no longer debug my User Interface. Setting IE back to the default browser fixed it. Alternatively you can attach the process plug-in during debug.
I had the same problem with my desktop application and as this forum says you should mark your project as a startup project, since visual studio has unmarked. It worked just fine for me an I believe it will help other people that may have this problem, since I believe you have finished this project.
One of my VB .NET Winforms projects wouldn't allow debugging.
This was due to the configuration manager set to 'Release' even though the toolbar dropdown indicated 'Debug'.
You need to select the mode dropdown and select the last option 'Configuration Manager' and ensure that the main project is set to 'Debug' and not 'Release'
Install Microsoft SSDTSetup.exe 450Kb and Close the SSDT tool during install. After installation open the SSDT tool and execute the script task and Component with breakpoint. Worked for me
try checking your output without debugging
Ctrl + F5
good luck
I have an asp.net web app, and I have added some related class projects to my solution file. When I run the web app, I want to break and step through the code in the class (when a class is referenced).
I don't get an error messages. The code in the class project just does not kick in.
I have searched and read this post Debugging a Class Library but no luck.
How do I get that to work?
Can you try to stop the ASP.NET process? I usually have this problem when the asp.net service is still running, and I compile (by asp.net service I mean the icon that appears near computer clock). Try to close that, recompile, then run.
Are you sure you have <compilation debug="true"/> set in your web.config file? Are the classes in the same assembly as the rest of the application?
edit: The only other thing I can suggest is stop IIS and/or all instances of the vs development server, clean the project, rebuild, and give it another shot. Also be sure there is only one web.config and you aren't running in release against Web.Release.config or something.
This sometimes happens. Check Debug>Modules to see if there is your dll loaded. It seems that VS debugger doesn't have .pdb file available. Clear Temporary ASP.NET Files in your .NET folder, Clean/Rebuild and try debug again.
Also do not forget to run VS as Administrator. Try to Attach to process instead of F5.
You can call in your code this function, and the debugger will pop-up
System.Diagnostics.Debugger.Launch();
alternative you can call the Debug.Fail("Stop me to see what next");
I have an ASP.NET MVC (beta) application that I'm working on, and am having trouble figuring out if I'm doing something wrong, or if my Application_Start method in Global.asax.cs is in fact not firing when I try to debug the application.
I put a breakpoint on a line in my Application_Start method, and am expecting that when I attempt to debug the application that the breakpoint should get hit... but it never does. Not after I reset IIS, not after I reboot, not ever. Am I missing something? Why is this method never getting called?
Note : a nice easy alternative to using the inbuilt "Visual Studio Development Server" or IIS Express (e.g. because you are developing against IIS and have particular settings you need for proper functioning of your app) is to simply stay running run in IIS (I use the Custom Web Server + hosts file entry + IIS binding to same domain)
wait for debugging session to fire up ok
then just make a whitespace edit to the root web.config and save the
file
refresh your page (Ctrl + F5)
Your breakpoint should be hit nicely, and you can continue to debug in your natural IIS habitat. Great !
If this is in IIS, the app can get started before the debugger has attached. If so, I am not sure if you can thread sleep long enough to get attached.
In Visual Studio, you can attach the debugger to a process. You do this by clicking Debug >> Attach to process. Attach to the browser and then hit your application. To be safe, then restart IIS and hit the site. I am not 100% convinced this will solve the problem, but it will do much better than firing off a thread sleep in App_Start.
Another option is temporarily host in the built in web server until you finish debugging application start.
The following helps in any case (no matter if you're using IIS, Cassini or whatever):
Set your breakpoint in Application_Start
Start debugging (breakpoint most probably is not hit) -> a page is shown in the browser
Change web.config (e.g. enter a blank line) and save it
Reload the page in the browser -> breakpoint is hit!
Why does this work? When web.config is changed, the web server (IIS, Cassini, etc.) does a recycle, but in this case (for whatever reason), the process keeps the same, so you keep attached to it with the debugger (Visual Studio).
I'm too having problems with breakpoints in application_start with IIS a hosted app. A good workaround is using Debugger.Break(); in code instead of the VS breakpoint
I have just the same problem. I have made a lot of renaming in my solution. After it I got two not working web-applications and several another web-applications were all right. I got error that I have wrong routes. When I have tried to setup break point in Application_Start method, and then restart IIS, VS didn't break execution. With workable web-applications break was working. Then I have recalled that "clean solution" and "rebuild" doesn't delete assemblies that left after renaming. And that was solution! I have manually cleaned bin directories of my buggy-web-applications and then saw new error in Global.asax Inherits="" attribute was referenced old dll. I have changed it on new and break began to work. Suppose that, during renaming Global.asax wasn't updated, and IIS took old assembly (with wrong routes) to start application.
Had the same problem in a Project we had taken over after another vendor built it. The problem was that while there were a number of commands written by the previous vendor in Global.asax.cs, which might lead you to believe it was in use, it was actually being ignored entirely. Global.asax wasn't inheriting from it, and it's easy to never see this file if the .cs file is present - you have to right-click Global.asax and click View Markup to actually see it.
Global.asax:
<%# Application Language="C#" %>
Needed to be changed to:
<%# Application Codebehind="Global.asax.cs" Inherits="ProjectNamespace.MvcApplication" Language="C#" %>
Where ProjectNamespace is whatever the namespace is of your Global.asax.cs class (usually the name of your Project).
In our case the file contained a bunch of inline code, some of which was copy-pasted from the .cs file, some not. We just dumped the inline code over to the .cs file and gradually merged our changes back in.
Try switching the managed pipeline mode for the app pool to "Classic" instead of "Integrated". That solved the problem for me. Looking into the reason now...
(Props for this answer belong to Flores (see his comment on his own answer), I just wanted to provide this as a separate answer to draw more attention to it)
Make sure that your global.asax in not under a subdirectory. It has to be placed at root level into your project.
We had a similar problem, where global.asax.cs was being ignored.
It turns out that the site was upgraded from a precompiled .NET 2 web site to a .NET 4.0 site. On the server, the PrecompiledApp.config file had not been deleted from the root folder. After deleting it, and recycling the IIS app pool and touching web.config to restart the application, code in Global.asax.cs started working fine.
I had a problem once where the Global.asax and Global.asax.cs were not actually copied to IIS folder by the deployment scripts...
So it worked when debugging on the development server, but not under IIS.
A late entry...
To test whether or not the IIS Application gets started before the debugger has had enough time to attach just add this to the top or bottom of your GLOBAL.ASAX's Application_Start.
throw new ApplicationException("Yup, it fired");
I faced this problem when using a static page (e.g. index.html) as the start up page - Application-Start does not get called. I discovered that serving a static page does not actually start the application. Requesting an .aspx page does.
Make sure the namespaces in Global.asax and Global.asax.cs are same. If they are different it will not throw any error but will not hit the breakpoint also because it is not executing application_start at all.
When you say "debug", do you mean actually launching the application from Visual Studio's built-in webserver for debugging, or do you mean attaching to the process in IIS? If it's the former, you should hit Application_Start, but if it's the latter, it can be difficult to be on the process early enough to catch it.
Close Visual Studio and delete the bin and obj folders in your web project (or all projects in the solution).
Here are commands to delete these folders from all of your projects:
rm *\bin -r
rm *\obj -r
I had made some changes based on "Code Analysis on Build" from Visual Studio. Code Analysis suggested "CA1822 Mark members as static" for Application_Start() in Global.asax. I did that and ended up with this problem.
I suggest suppressing this Code Analysis message, and not alter the signature of methods/classes automatically created by platform used for bootstrapping the Application. The signature of the method Application_Start probably was non-static for a reason.
I reverted to this method-signature and Application_Start() was firing again:
protected void Application_Start()
{ ... }
I think the application start event only gets fired when the first request is made, are you hitting your website (i.e. making a request)?
I had this issue in a .net 4 web forms vs2010 project and tried everything mentioned on this page. Ended up removing and adding global.asax actually resolved the issue for me.
I hade the same problem, couldn't catch Application_Start.
And the reason was that it was not firing do to a missmatch in the markup file.
The markup file Global.asax was inheriting another class...
Did you check the Project settings?
I had this problem and I had the Start URL going to a different port than my server specific port.
It took me too long to figure out...
After trying as many of the other answers as were applicable in my situation and having no luck with any of them, I went into the properties for the Web project (the server-side project for a Silverlight app using RIA Services), clicked on the "Web" tab and changed the selected Server from "Local IIS" to "IIS Express". (Note I'm using VS2013.) This solved the problem. Application_Start executes under "IIS Express" but not under "Local IIS". Interesting...
I was trying to step through code in RegisterRoutes() called from Application start and not hitting my breakpoint. I determined Application_Start was not getting called. I had to make a change to make a superficial change to App_start/RouteConfig.cs and save it before Application_Start would get called. I guess these files get cached somewhere and are not called unless a change is made.
My same issue has been resolved by Adding reference of System.Web.Routing assembly in project
If you are using the System.Diagnostics.Debugger.Break(); workaround (which I think is just fine for temporary use) and it's "just not working" on your Windows 8 Machine. The reason is a bug in Visual Studio's "Just in time debugging".
The fix is as follows is to fix the key for the "Visual Studio Just-In-Time Debugger"
Open regedit and go to HKEY_CLASSES_ROOT\AppID{E62A7A31-6025-408E-87F6-81AEB0DC9347}
for the ‘AppIDFlags’ registry value, set the flag to 0x8
More info here:
http://connect.microsoft.com/VisualStudio/feedback/details/770786/just-in-time-debugging-operation-attempted-is-not-supported
In my case, killing the built-in ASP.NET Development Server instance via the system tray resolved the issue.
Weird and crazy stuff... but debugging on a server machine and another user left IIS Express running on their session. I had to logoff that user to kill his running IIS Express processes. That seems to have fixed the problem!
Update
After spending more than 1 hour chasing what was causing the problem... here's the deal: I somewhat managed to type an s inside the <appSettings> section in Web.config. Visual Studio tried to warn me in the Error List window with a warning. I confess I rarely check warnings... should start checking it from now on. :D As soon as I removed the offending s the breakpoint got hit in Application_Start.
I had this problem when trying to initialize log4net. I decided to just make a static constructor for the Global.asax
static Global(){
//Do your initialization here statically
}
Problem mainly occurs when you try to relocate the Global.asax file to another solution directory. Relocate the Global.asax file again into the default location. It will work as expected.
None of the solutions described above worked for me.
However reinstalling the package
Microsoft.CodeDom.Providers.DotNetCompilerPlatform
using nuget gui is a (not too nice) walkaround