Lately, VS has been getting more and more annoying about warning me about editing code while debugging. Regardless of whether it is a popup telling me that a file has been edited, purple underlining, or a warning that gets grouped with the compiler warnings and errors, I don't want it. I wish it would just let me edit, continue running the program that was built, and keep quiet about it.
Is there a way to tell it to do that?
Incidentally, I have already disabled edit and continue. See Edit and Continue: "Changes are not allowed when..."
You can apply changes to the source code in debug mode when you stop at a breakpoint.
Manual: How to: Apply Edits in Break Mode with Edit and Continue (Visual Basic)
This is a workaround but some workarounds, well, work.
Run two instances of VS on the same solution. Debug one and encounter needed edit. Ctrl+TAB to the other instance and make the edit (without saving... by the way use auto-save). Continue until you’re done, and then save the files in instance 2. After debug, the changes are available to both instances.
Rarely (at least in my experience) do you actually want edit-and-continue; usually you’re watching the code under debug and realize it is wrong and want to fix it, but also want to see some downstream effects without killing the debug session.
This gives you that with a minor inconvenient task switch.
Related
For some unknown reason, my visual studio adds many break marks in my code.
Some where I believe i had some in the past and some in utterly nonsense positions.
I have found nothing in the web. Dont know if thats a bug or if I am using it incorrectly.
Anyone had that before or knows how to resolve this?
I can remove them point by point until my app runs through but as soon as I start debugging, they are beeing readded. When I stop debugging, they are gone again. I was even able to capture one sample beeing added:
It litterally makes debugging impossible. I cant remove 50 break points whenever I want to debug...
Workaround #1
I have found kind of a workaround by going over Debug -> delete all Break points.
Be aware, this will delete your wanted breakpoints as well.
I have a really strange problem with my Visual Studio.
I usually press CTRL + S pretty often (call me paranoid, well however I got that habit some years ago now and I really don't want to get rid of it :-))
Now I had the issue that I was editing one file, changing a few dozen of strings according to a spec I had open in Word; so I switch around these two tasks pretty often, make one or two changes and then save.
The odd thing is, every once in a while, after saving, my file is suddenly in read-only-mode, so I cannot navigate through my changes (CTRL+Z/CTRL+Y) and have to reopen that file to continue to code and pray.
Indeed it feels random to me when this occurs:
sometimes I only change 1 thing and save and then it's immediately read-only,
well in other cases it will let me edit several things until it is stuck.
Someone else also experiencing this and maybe got a tip?
Maybe I hit some magic hotkey or something?
My bad, please check if your projects folder is not a synchronized one, so when you edit (change) your project, the backup tool starts to update in remote location for synchronization purposes, so locks the file.
The answer to this problem is most likely that you are currently in Debug mode - i.e. the application is being run. Click "Stop" and it'll allow you to edit the files again.
By default, you cannot edit source files while the Debugger is running.
The text sent is not seen in the Output window.
Solution Configuration is Debug.
Output window is showing output from Debug.
It's a simple command: Debug.WriteLine("abc");
Setting a Breakpoint on it succeeds, but the program breaks on the line after it, moving the Breakpoint!
Changing Platform from Any CPU to x86 solves the issue. But going back, it returns.
Creating a new solution, it does work. Even in Any CPU.
I removed the .suo file for the solution.
I emptied the %temp% folder.
Is there any solution for this?
1) Go to Build -> Configuration manager and make sure you are in Debug mode, not Release.
2) Right-click on the project that you're having trouble with and choose properties.
3) Check the Build tab and make sure Define DEBUG constant and Define TRACE constant are both checked.
Note, most people make the mistake corrected by Step #1. But in my case it was steps #2 and #3 that fixed the problem. Despite being in DEBUG mode, for some reason those two constants were not being defined! I think the IDE may have turned them off when I had some of the projects in a solution using one platform target, and the rest of them using a different one, because by default, they are both enabled (checked) when you are in Debug mode.
I have a VS solution containing several projects. While debugging a particular project all the source files are locked by VS. I would like to unlock sources that the debugee doesn't have dependency on. Is there any way to do this within one solution?
UPDATE:
I'm using Win XP SP3 32bit. Visual Studio 2010, C#. Edit and Continue is enabled. The solution contains 6 projects (number in not important actually), 5 of them depend on the data access layer project which uses Entity Framework. None of the 5 have any mutual dependencies. They are WinForms and Console applications. I would like to be able to run one of the projects and make changes to others without stopping the first. The problem is starting and stopping the project take considerable amount of time.
The Edit and Continue feature is preventing you from editing files if the debugger hasn't stopped the program. The simple workaround is Debug + Break All, you should then be able to edit the files, your changes will be immediately effective provided your changes do not violate the restrictions imposed by E+C. This is the most efficient work flow.
The heavy-handed approach is to disable Edit and Continue. Tools + Options, Debugger, Edit and Continue, uncheck the Enable check box.
I don't think that there is a way to avoid that. While debugging Visual Studio lock all files to prevent any change on them, including those on other projects.
You can try to open the project which you are interested on with another Visual Studio instance to make changes to your files or open files singularly with another editor.
This doesn't quite answer the OP's question per se, but for anyone who has stumbled upon this page in the same (very frustrated) boat as I am, this might help.
The solution: start without debugging.
It was driving me absolutely crazy that Visual Studio would not let me edit files while the app was running. My typical workflow is:
Make some changes
Run the app to see the effects of those changes
Based on the results, make more changes, etc. etc.
The problem is Visual Studio was preventing me from step 3. It demands that you STOP running the app before you can even make any changes (including to a XAML file or adding a file to the project), which also means that you can't go back to the app to double-check something while you are actually programming it at the same time (which is how I work, bro).
Thank god I finally discovered if I run without debugging it doesn't impose this ridiculous limitation. It's still a pain in the butt if you actually need to debug something you have to re-run the app in debug mode, but it sure beats having to kill the app before it will even let you edit a file.
I set a breakpoint in my code in Visual-C++, but when I run, I see the error mentioned in the title.
I know this question has been asked before on Stack Overflow (Breakpoints cannot be set and have been disabled), but none of the answers there fully explained the problem I'm seeing. The closest I can see is something about the linker, but I don't understand that - so if someone could explain in more detail that would be great.
In my case, I have 2 projects in Visual C++ - the production dsw, and the test code dsw. I have loaded and rebuilt both dsws in debug mode. I want a breakpoint in the production code, which is run via the test scripts. My issue is I get the error message when I run the test code, because the break point is in the production code, which isn't loaded up when the test starts.
Near the beginning of the test script there is a mytest_initialize() command. I imagine this goes off and loads up the production dll. Once this line has executed, I can put the breakpoint in my production code and run until I hit it. But it's quite annoying to have to run to this line, set the breakpoint and continue every time I want to run the test.
So I think the problem is Visual C++ doesn't realise the two projects are related. Is this a linker issue? What does the linker do and what settings should I change to make this work?
Thanks in advance. Apologies if instead I should be appending this question to the existing one, this is my first post so not quite sure how this should work.
[Update 1] I think Chris O has identified the problem. I'll add a further update if I'm able to work out how to use the project settings to make this work.
It sounds like you are using VC6, since you mention dsw files. I think that is as good as it gets in VC6, you have to manually add the breakpoint after your module is loaded from LoadLibrary. Actually, there might be a project debug setting, so you can specify which DLLs to load when debugging your project, that will keep your breakpoints enabled when hitting F5.
You can also try attaching the debugger after you know the mytest_initialize() has been called, that might keep your breakpoints enabled.
I had this issue sometimes, but always pass this with some code replacement actions.
Here is some guy post, how he had fixed it.
Hope it helps.
In my case i solved this by setting the DLL project containing the breakpoint as Active Project and changed Debug settings for this project (right-click project>>settings>>Debug tab) to point to the project that actually runs and accesses the DLL. "Executable for debug session:" and "Working directory:" should be set to the executable that you actually want to run and its corresponding directory.
Hope this is of any help.
right-click project>>settings>>Link tab
check on Generate debug info
check on Link incrementally