I am working on a C#.NET class library project in VS2010. In my project settings -> debug settings, I have the project set to start an external program (C:\Windows\SysWOW64\wscript.exe) which runs a very simple jscript file (test.js). The script simply creates an instance of the class and calls one of it's methods.
The problem is when I start debugging, VS2010 does not stop at any of my breakpoints. If I open up the exact same project in VS2008 it does stop at the break points. Is there a new setting somewhere that is preventing the breakpoints from being hit? Has anyone else ran into this issue?
My first check would be to disable "Just My Code"
Tools -> Options
Debugger
Uncheck "Enable Just My Code"
Try the scenario again.
To solved this problem by creating a config file for the application which is using the component to debug with the following data:
<?xml version="1.0"?>
<configuration>
<startup>
<supportedRuntime version="v2.0.50727"/>
</startup>
</configuration>
With this file you tell the debugger to use the right runtime version for debugging (it seems the debugger uses version 4.0 by default).
I have a tried a whole day to find out why I couldn't debug my visual studio 2012 console application, and the answer was embarrassing.
I was running it in "RELEASE" mode.
Sometimes the obvious is the hard to find.
Close the Visual Studio IDE and Open it. Now it will work. For me it also face the same issue. I used this way to overcome
I had a "Rebuilt" VS2013 project that I couldn't debug (no symbols). Finally, I saw Optimization was checked (Project->Properties->Build). I unchecked it and Rebuilt. Symbols loaded finally. My two cents, only use (compile) Optimization when absolutely necessary.
While I can't answer why it happens, I can provide you with workaround.
Include
using System.Diagnostics;
At the very beginning of your code (Class constructor for instance) place the following lines:
#if (DEBUG)
while(!Debugger.IsAttached);
Debugger.Break();
#endif
Start debugging.
Menu Tools→Attach to Process
Attach to your process.
breakpoint should trigger in your code.
Other breakpoints should trigger as well.
Could be a number of reasons. Usually it's because you're trying to debug against the wrong version.
These actions work about 80% of the time.
Get the latest code
Clean
Rebuild
Restart IIS
Try again
If no good, go to Debug > Windows > Modules and if the relevant dll is there, right click it and load symbols.
If it's not in the list, try running the code anyway. Sometimes even though it says the breakpoint will not be hit, it's only because the dll is not loaded until you enter a scenario that needs it. Try the scenario that depends on the dll, and it may just hit the breakpoint anyway.
Oh one more idea, restart your browser. You might have something cached from an older dll.
If the reason is wrong .NET runtime version (which was my problem), instead of creating configuration file you can simply choose the right version in the Attach to process dialog.
In the dialog, next to Attach to click on Select and switch from Automatically... to Debug these code types where you should check the right version.
If this was your problem also, then you probably had "Symbols not loaded" message on your breakpoints. Immediately after selecting the right version you should see that this error is no longer reported.
For me it was fixed by:
Open the project properties is VS2010
Goto Compile -> Advanced Compile Options
Change 'Generate debug Info' from 'None' to 'Full'
The problem could be your browser is using a cached version of the page, you are working with.
Try to add som nonsense extra querystring in your adress line of the browser f.x. add ?NONSENSE=1234
This forces the browser to use a new version of the web page since it does not know if the page should look different with this Query in the end. Next time use ?NONSENS=1235.
I had a problem with misplaced breakpoints in my native c++ code.
The reason was I had been editing the code so some line ends in the code was not \r\n. It was not possible to see in the code unless you searched for \r\n.
After inserting the proper line ends \r\n the debugger worked.
I encountered the similar issue but its in a CLR project. I had some old c++ syntax in the CLR project. For me after I enabled 'Use managed compatibility mode' in Tools>options>Debugging>General it started to hit the break points.
Related
I am dealing with a puzzling situation here,and need any help I can get . I am using Visual Studio 2008 and have a dev site running on IIS. When I Attach to the process running in IIS, it attaches successfully(no errors). However when I attempt to debug, nothing happens. I have closed out my browser, done a restart on the application pool, and website, cleared cache, and even forced a rebuild in visual studio. Still I am unable to step into code. Any idea what I could have wrong here?
The breakpoint will not currently be hit. No symbols have been loaded for this document.
Your symbols might be wrong or missing. In extra rare circumstances you might need to step inside the function via assembly, only then VS picks up that you're actually calling your component.
Check if you have you set compilation debug=”true” in you web.config file?
I believe you need to debug the website from within Visual Studio in order for breakpoints to be hit. Use the green "play" button, or use F5, or just go to Debug > Start Debugging.
The answer to this has got to be simple, but I sure don't see it.
I'm working on an MVC2 project under VS2010, with Unit tests written in NUnit.
I debug the tests (and code) by starting the NUnit GUI, then clicking Debug -> Attach To Process in VS, and attaching to nunit-agent.
This has all worked fine for some time.
I added one additional test for a bug that I discovered this morning, and suddenly, my breakpoints are not being hit. NUnit just runs merrily along and says the test passes (which it shouldn't, since I haven't fixed the bug yet), without ever stopping at the breakpoint I have set on the very first executable line in the test method.
I've looked at everything I can think of, including rebooting the machine, and I can't figure out what has changed. (FWIW, the test project is configured to run under .NET 3.5, and I'm running NUnit 2.5.4. I have added the 4.0 "supportedRuntime" flag and "loadFromRemoteResources" flag to the section of nunit.exe.config, and I have also tried attaching to nunit.exe instead of nunit-agent.exe. Note that I am NOT getting the disabled breakpoint buttons with the "source code cannot be loaded" messages. The breakpoints are the standard red ball, they just never get hit.)
The answer was indeed simple.
Somewhere along the line, I had been using VS2010 to debug Script code by attaching to the browser. When you attach to a process in the debugger, you have to tell it what kind of code you are debugging, and debugging script code is incompatible with debugging managed code, so it turns off Managed code. Apparently VS remembers your last selection.
So when I attempted to attach to N-Unit, it was selecting Script as the type of code that I wanted to debug, and I didn't notice. All I had to do was select the drop down box in the "Attach to process" dialog box, and check managed code.
Thanks to Paul Laudeman in his CodeBetter Blog
Try attaching to the nunit-agent.exe process. That worked for me.
Sometimes I get the message that the breakpoint will not be hit, and no symbols will be loaded.
The red icon in vs.net changes color, and the debug mode just doesn't work.
what is the reason for this?
You may be running your project in Release mode. If so, then switch to Debug mode
From Visual studio debugging issue with files of the same name by Philip Carney
Do each bullet in the link below ONE AT A TIME, but repeat my steps below with each one you try.
Stop debugging (press red square icon) in Visual Studio
Clean Solution
Build Solution
Tools > Attach to Process (or start with debugging)
Start the program that you're attaching to, and run it such that your code will get hit
If attaching to nunit.exe, then open NUnit and run a test so your breakpoint will be hit
If attaching to w3wp.exe (IIS site), then open your site in the browser and go to the page that will hit your breakpoint
for manage code only - theres a good answer for this problem on the following site:
http://geekswithblogs.net/dbutscher/archive/2007/06/26/113472.aspx
for native + managed code - in the startup solution properties-> Debug tab
make sure that "enable unmanaged code debugging" check box is checked
After trying several suggested fixes for this I did the following to get it working.
Right Clicked my Project in the Solution Explorer and selected "Properties".
Went to the "Web" section and made sure "Start Action" was set to "Current Page".
Spent 3 1/2 hours on that... I'm going to go get a drink now.
I resolved this problem by selecting Automatic:Native Code for the "Attach to" field in "Attach To Process" form
Next to the "Debug/Release" dropdown list, there is another one with "Any CPU/Configuration Manager...". Click "Configuration Manager...", and you will see some of your projects might be in Release mode. Change all of them to Debug.
This can happen if the symbol fiels are different from the assembly (remote debugging), or when there is no "direct path", so the assembly hasent been load, but might be loaded using reflection and loading of the required assembly at run time.
This can also happen if the debugger is not attached to the process for whatever reason. If it's the case, you can always go to Debug - Attach to Process... and choose the right process. Your breakpoints should return to normal once VS determines it can hit them.
What does it say when you hover the mouse over the disabled breakpoint? It will usually tell you the problem. My favorite is the old 'source code is out of date', especially when I'm debugging a DLL. Another favorite is when the file you're looking at isn't the one you're debugging (a copy in another folder?). If it's a case where you can breakpoint a caller routine, but not the callee, stepping into the callee will force VS to open the 'proper' source file and you'll be able to set breakpoints. Confusing, I usually swear at VS at this point, it seems to help.
I had the same problem. Which I know is normally if the build versions are different, and something isn't matching up. I cleaned my project, rebuilt it, and then deployed and that got everything back in-sync.
I do not like to play with knives but the only thing that worked for me involved editing the .csproj file itself. So, unload the project file, edit it by cutting and pasting the three asp.net files so that they are together in the ItemGroup. However, sometimes it is necessary to go further as explained here: http://carnotaurus.tumblr.com/post/4130422114/visual-studio-debugging-issue-with-files-of-the-same - Also, I give a list of other proposed solutions that did not work for me. I hope it helps.
I have tested with both deployed application and service, what I have found out that If the deployed code is different than a code in visual studio then breakpoint will not hit. Even small changes will affect and the breakpoint will not hit. So, It is better to debug the same version which is there on vs code and also in deploy application or service.
To fix this I had to re-create the virtual directory. I'm using Asp.Net 4.7 Framework and IIS Express. Went to Web project > property page > Web tab > clicked the "Create Virtual Directory" button next to Project Url textbox.
I forgot I had clicked this button in my "Main" branch, but then had switched to my "Sprint" branch. It kept running the "Main" code until I clicked "Create Virtual Directory" on my "Sprint" branch.
For me it was giving this because I haven't started the relevant project at start of application , it worked after I added project run on start
Even if I create a clean WinForms project, Edit and Continue doesn't work and gives me the error:
Changes are not allowed when the debugger has been attached to an already running process or the code being debugged was optimized at build or run time.
Edit and Continue option is checked in Tools → Options → Debugging.
Optimization is not enabled.
Seems like there is no any managed profiler set up.
I am running in Debug mode
I am running on x64 CPU and Windows XP 32-bit, but setting platform target to x86 rather than AnyCpu doesn't help.
Repairing Visual Studio installation doesn't help.
I also found this article on MSDN website:
Unsupported Scenarios
Edit and Continue is not available in the following debugging scenarios:
Debugging on Windows 98.
Mixed-mode (native/managed) debugging.
SQL debugging.
Debugging a Dr. Watson dump.
Editing code after an unhandled exception, when the "Unwind the call stack on unhandled exceptions" option is not selected.
Debugging an embedded runtime application.
Debugging an application with Attach to rather than running the application with Start from the Debug menu.
Debugging optimized code.
Debugging managed code when the target is a 64-bit application. If you want to use Edit and Continue, you must set the target to x86. (Project Properties, Compile tab, Advanced Compiler setting.).
Debugging an old version of your code after a new version failed to build due to build errors.
But I can answer "No" to every item in this list.
It worked before, but several days ago it stopped working, and I don't know what could be the reason.
Other Applicable Solutions:
Below is an incomplete, unordered list of possible solutions to try if you* are trying to fix Edit & Continue quickly.
Make sure you are in Debug Mode
Make sure you're not launching a mixed mode process
Try to set the CPU target to x86 rather than AnyCPU (on x64 machines)
Uncheck the Optimize Code checkbox for Debug Mode in Project Properties->Debug
Uncheck the Optimize Code checkbox in Project Properties->Build
Uncheck Enable Optimizations in Advanced Compiler Settings
(ASP.NET) Check nightcoder's answer if it is the case
(ASP.NET) Check this answer (by matrixugly) if it is the case
(ASP.NET) Ensure you have Edit and Continue enabled on the Web tab (vs2010)
(ASP.NET) Go to Properties > Web > Servers, and make sure that Enable and continue is checked under Use Visual Studio Development Server.
(ASP.NET WebAPI) Make sure you've stopped in the Controller's method using a breakpoint, before trying to edit it.
(vs2017) Go to Tools > Options > Debugging and uncheck (deselect) 'Edit and Continue'. This is actually the opposite of the 'conventional' advice (see some other points in this post). It does not allow you to actually make changes in your running program (i.e. it does not hot-swap the code changes that you make) - it simply allows you to edit your code (i.e. it prevents that annoying message and "locking" your editor).
Go to Tools > Options > Debugging > General and make sure Require source files to exactly match the original version is unchecked.
Check Enable Windows debug heap allocator (Native only) [VS Community 2017]
Are you using Microsoft Fakes? It inhibits Edit & Continue.
Kill all the *.vshost.exe instances by selecting End Process Tree in the Task Manager. VS will regenerate a correct instance.
Remove all the breakpoints with Debug->Delete All Breakpoints
Enable and Continue exists in both the Tools > Options > Debugging menu and also in the Project Settings. Be sure to check both places. edit & Continue is not supported with the extended Intellitrace setting.
Be sure Debug Info in Project Properties > Build > Advanced > Output > Debug Info is set to Full
Some plugin may be interfering. Check by disabling/uninstalling and then trying again the other solutions.
If you're not paying enough attention, the error you get while trying to fix this may change to something else that is easier to diagnose. E.g. A method containing a lambda expression cannot support edit and continue.
Make sure the System variable COR_ENABLE_PROFILING is not set to 1. Some profilers set this when installing and leave it like that after uninstalling. Open a command prompt and type set to quickly check it your system is affected, if so remove the variable or set it to 0:
In Windows 8 and above, search for System (Control Panel).
Click the Advanced system settings link.
Click Environment Variables.
Remove COR_ENABLE_PROFILING
Be aware of unsupported scenarios (as reported in the question) and that unsupported edits.
* by 'you', I mean the visitor of the page who is hammering his head on a keyboard to find The solution.
Feel free to edit this answer to add your workaround if not listed here!
If you're debugging an ASP.NET application, go to properties > web > Servers, and make sure that "enable and continue" is checked under Use Visual Studio Development Server.
I finally got to solve the problem: UNINSTALL Gallio
Gallio seems to have quite some many rough edges and it's better to not use MbUnit 3.0 but use the MbUnit 2.0 framework but use the gallio runner, that you are running without installing from the installer (which also installed a visual studio plugin).
Incidentally, I had the issue even after "disabling" he Gallio plugin. Only the uninstall solved the problem.
PS. Edited by nightcoder:
In my case disabling TypeMock Isolator (mocking framework) finally helped! Edit & Continue now works!!!
Here is the answer from TypeMock support:
After looking further into the edit
and continue issue, and conversing
about it with Microsoft, we reached
the conclusion it cannot be resolved
for Isolator. Isolator implements a
CLR profiler, and according to our
research, once a CLR profiler is
enabled and attached, edit and
continue is automatically disabled.
I'm sorry to say this is no longer
considered a bug, but rather a
limitation of Isolator.
I had the same problem. I even re-installed VS 2008 but the problem did not go away. However, when I deleted all the break points then it started to work.
Debug->Delete All Breakpoints
I think it was happening because I had deleted an aspx page that had break points in its code, and then I created another page with the same name. This probably confused the VS 2008.
"Edit and Continue", when enabled, will only allow you to edit code when it is in break-mode: e.g. by having the execution paused by an exception or by hitting a breakpoint.
This implies you can't edit the code when the execution isn't paused! When it comes to debugging (ASP.NET) web projects, this is very unintuitive, as you would often want to make changes between requests. At this time, the code your (probably) debugging isn't running, but it isn't paused either!
To solve this, you can click "Break all" (or press Ctrl+Alt+Break). Alternatively, set a breakpoint somewhere (e.g. in your Page_Load event), then reload the page so the execution pauses when it hits the breakpoint, and now you can edit code. Even code in .cs files.
Couple of things to check
Make sure your compile is set to Debug vs. Release
Make sure you're not launching a mixed mode process
If on a 64 bit machine Make sure to set the CPU target to x86 rather than AnyCPU
EDIT
I don't believe this should matter but make sure that the hosting process is enabled for the target platform. Probably won't help.
If it repros for new projects then it might be something even more subtle. I would try the following.
Backup HKCU:\Software\Wow6432Node\VisualStudio\9.0 (maybe just rename it)
Delete the same key
Try the repro again
None of the above solutions worked for me(running on a 64x machine).
Finally I clicked on 'advanced compiler settings' and UNCHECKED 'enable optimizations' and I can now step through code and edit while debugging.
For me, for a reason that I don't understand, the setting "Generate debug info" in the "Advanced Compiler Settings" was set to "pdb-only" instead of "Full".
By default, this parameter is always set to "Full" but a mysterious poltergeist has changed this parameter on last night. :)
P.S. I'm in Visual Basic .Net with Visual Studio 2010
If your concern is with an ASP.NET app, ensure you have edit and continue enabled on the web tab (vs2010). There was also a separate setting for ASP.NET debugging in earlier versions.
Regards,
Adam.
I found that even though under project properties build & debug tab are set to Debug and all the other setting are correct I still get the message, however after digging some more
under the Build menu select Configurations Manager... and make sure Debug is selected in two places there as well. go figure...how many different places do they need to set debug?????? even though you set Project - Configuration to Debug then under Build - Manager it is not changed so you have change the same setting there as well Project Configuration - seems like a microsoft issue again.......
This problem is due to Intellitrace setting
If Intellitrace is enabled make sure Intellitrace event only is checked
Otherwise this will not allow edit and continue..
If you will click on Intellitrace options you will see the warnings.
Following shooting helped me using VS2010:
go to Tools, Options, Debugging, General and make sure "Require source files to exactly match the original version" is unchecked.
That happens when the debugger hasn't hit a breakpoint or you haven't hit Break All (pause). It couldn't be that simple could it?
The error says a possible cause is: "the code being debugged was optimized at build or run time". Go to Project Properties->Debug and uncheck the Optimize Code box for Debug mode.
I had this problem in Microsoft Visual Studio 2008 and the solution is easy. when you run your project please set in "Debug" mode not "Release". The another people solution can be useful.
If I create a new project, edits while debugging do not work. If I create a new website, edits while debugging work as expected.
I ran into this today - turns out that having Debug Info set to pdb-only (or none, I'd imagine) will prevent Edit and Continue from working.
Make sure your Debug Info is set to "full" first!
Project Properties > Build > Advanced > Output > Debug Info
In my case just reseting to default debugger settings and setting IntelliTrace-> only intellytrace events helps
Some things that seemed to help using VS2010:
go to Tools, Options, Debugging, General and make sure "Require source files to exactly match the original version" is unchecked.
multiple .vshost.exe instances can be left over from e.g. detaching the VS debugger from a stopped process. This will interfere with breakpoints and compiles as well. Use Task Manager, Processes tab to kill all instances of .vshost.exe by right-clicking each instance and selecting End Process Tree. VS will create a new instance.
I removed a dataset from my project because I didn't use it. After that I could modify the program when debugging.
I did all the changes mentioned in every other answer and none worked. What did I learn? Enable and Continue exists in both the Tools > Options > Debugging menu and also in the Project settings. After I checked both, Enable and Continue worked for me.
Seems illogic, but only way was disabling edit and continue from VS 2017 options... Then AspNet edit and continue began to work...
what worked for me was unchecking "Use Managed Compatibility Mode" under
Tools -> Options -> Debugging
TBN: checking or unchecking "Require source file to exactly match the original version" seems not influences the E&C
Hope this can help.
Enable edit and Continue only work run IIS Express.
Don't work in Local ISS or External Host.
I'm adding my answer because the thing that solved it for me isn't clearly mentioned yet. Actually what helped me was this article:
http://www.rubencanton.com/blog/2012/02/how-to-fix-error-changes-are-not-allowed-while-code-is-running-in-net.html
and here is a short description of the solution:
Stop running your app.
Go to Tools > Options > Debugging > Edit and Continue
Disable “Enable Edit and Continue”
Note how counter-intuitive this is: I had to disable (uncheck) "Enable Edit and Continue".
This will then allow you to change code in your editor without getting that message "Changes are not allowed while code is running".
Note however that the code changes you make will NOT be reflected in your running program - for that you need to stop and restart your program (off the top of my head I think that template/ASPX changes do get reflected, but not VB/C# changes, i.e. "code behind" code).
I install the stackify, when i enable this on icon tray, it stop my debugging with edit, so i found
Close the visual studio , in my case its vs2017
Go to icon tray and right click on stackify icon and disable .NET Profiler
Open Visual studio run application again in debug mode with debugger and it allow me edit while debugging
I had this annoying issue since I upgraded my VS 2019 to 16.4.3 and caused me a lot of headache.
Finally I solved the problem this way:
1. Stop Debugging
2. Select the solution from "Solution Explorer"
3. In the Properties window change the "Active config" Property From "Release|Any CPU" To "Debug|Any CPU"
4. In Debug > Options > General Check the Edit and Continue checkbox
That worked for me, and hope it works for you too.
embed interop types visual studio should be set to false
I had this happen in a linked class file. The rest of the project allowed E&C, but I got the same error editing the linked file. Solution was to break linked file into it's own project and reference the project.
I faced the same problem. My problem was that I could modify a file, but not another (both are in same project). Later I found that the file I couldn't modify was also part of another project. That another project (Unit Test) wasn't loaded, and intelligent VS debugger shows the error that assembly for this given file was not loaded, and changes aren't allowed. How weird!
Hence, I had to unload the unit-test project and continue the EnC debugging.
Is there a good way to debug errors in the Visual Studio Designer?
In our project we have tons of UserControls and many complex forms. For the complex ones, the Designer often throws various exceptions which doesn't help much, and I was wondering if there's some nice way to figure out what has gone wrong.
The language is C#, and we're using Visual Studio 2005.
I've been able to debug some control designer issues by running a second instance of VS, then from your first VS instance do a "Debug -> Attach to Process" and pick "devenv".
The first VS instance is where you'll set your breakpoints. Use the second instance to load up the designer to cause the "designer" code to run.
See Debugging Design-Time Controls (MSDN).
It has been a pain in 2005 and still is in 2015. Breakpoints will often not hit, probably because of the assemblies being shadow copied or something by the designer(?). The best you can do is to break manually by introducing a call to Debugger.Break(). You may wrap it into a compiler conditional as so:
#if DEBUG
System.Diagnostics.Debugger.Break();
#endif
int line_to = break; // <- if a simple breakpoint here does not suffice
I have had this happen many times and it is a real pain.
Firstly I'd suggest attempting to follow the stack trace provided by the designer, though I found that often simply lists a bunch of internals stuff that isn't much use.
If that doesn't work then try compiling and determining the exception from there. You really are flying blind which is the problem. You could then try simply running the code and seeing what exception is raised when you run it, that should give you some more information.
A last-gasp approach could be to remove all the non-generated code from the form and gradually re-introduce it to determine the error.
If you're using custom controls you could manually remove the generated code related to the custom controls as well if the previous method still results in an error. You could then re-introduce this step-by-step in the same way to determine which custom control is causing the problem, then go and debug that separately.
Basically as far as I can tell there's no real way around the problem other than to slog it out a bit!
I discovered why sometimes breakpoints are not hit. In the Attach to Process dialog, "Attach to:" type has to be "Select..."'d.
Once I changed to "Managed 4.0, 4.5", breakpoints for a WinRT application were hit. Source: Designer Debugging in WinRT.
Each one is different and they can sometimes be obscure. As a first step, I would do the following:
Use source control and save often. When a designer error occurs, get a list of all changes to the affected controls that have occurred recently and test each one until you find the culprit
Be sure to check out the initialization routines of the controls involved. Very often these errors will occur because of some error or bad dependency that is called through the default constructor for a control (an error that may only manifest itself in VS)
You can run a second instance of VS and attach it to the first instance of VS (Ctrl+Alt+P). In the first instance set the breakpoints, in the second instance run the designer, and the breakpoint will fire. You can step through the code, but Edit-and-Continue will not work.
For Edit-and-Continue to work, set you control library's debug options to run a VS with the command line argument being the solution filename. Then you can simply set the breakpoints and hit F5. It will debug just like user code! As a side note, you can do this will VS and Office add-ins also.
This worked for me for Visual Studio 2022:
I opened a second Visual Studio instance
In the second instance I clicked Debug -> Attach to Process...
I selected DesignToolsServer from the process list
More details: https://learn.microsoft.com/en-us/dotnet/desktop/winforms/controls/walkthrough-debugging-custom-windows-forms-controls-at-design-time?view=netframeworkdesktop-4.8