This has been driving me crazy and cutting down on my productivity all day. At one point for debugging I dragged an external file from another project into my current solution (Visual Studio 2010) so I could debug it as the class defined in it was being used by the solution I'm working on.
That was all well and good and after I was done I removed it from the solution and everything was normal. At some point however Visual Studio has decided that every single time I run my solution it will bring the external file back in as well as replacing the breakpoints that I used way back when for debugging. No matter how many times I remove the breakpoints and remove the external file from my solution this continues to happen every time I run.
I'm guessing there is some kind of file or setting saved somewhere that's telling VS to do this? Could anyone help me figure things out so I don't have to deal with breakpoints in a file I don't currently care about every time I need to run my application?
After stopping the debugger. Delete that break point manually either by opening that file or from the list of break points. Yes, visual studio stores this as part of the pdb file. Deleting that file is also an option if you don't mind losing all the debug information.
Related
While trying to debug an asp.net website in visual studio 2013 professional I am having a weird issue. The website is simple but uses flat files and folder structure and files in it for performing some operations. There are two important folder in this website that contains 100 thousands of files and images. When I try to start debugging and do not remove files from these two folder then VS crashes and restart, but if I remove files then VS proceeds normally. The files in these folders are csv, txt and image files. What I can understand is that VS goes through all these folders and files before starting the debugger, hence somehow I need to tell VS to not to consider these folders. I am not able to find anything related to it. Please help. Thanks in advance.
Perhaps take a look at your Event Viewer first and see if you can find anything regarding VS crash.
Also you can try running Visual Studio from the command line devenv.exe /log and then load your solution. If crash still happens, then go take a look at following file %APPDATA%\Microsoft\VisualStudio\<version>\ActivityLog.xml. Perhaps you would find some more details about the crash.
If you happen to be using ReSharper, you might want to disable it and see if that would make any difference. ReSharper likes to index source files in the background which could lead to some usability issue in VS.
Answering for anybody who faces similar problem.
For some reason I dont know why, when starting degugging visual studio was scanning each and every folder, even the folders which doesnt contained any code file, this was making VS very slow due to very high number of files and out of memory exception was being thrown. Since in my case these folders doesnt contained any code file, but still were needed to run the application, I made them hidden from window explorer. This solved the problem as now vs ignores them, while still the program can output report and read reports from these hidden folders.
Hello there, Stackoverflow.
Recently, when I've been programming in Visual Studio 2010, I've been getting the problem with VS locking the bin/Debug/(ProjectName).exe file when trying to build and gives me the error below after trying to build the project 10 times:
Unable to copy file "obj\x86\Debug\TileEngine.exe" to "bin\x86\Debug\TileEngine.exe". The process cannot access the file 'bin\x86\Debug\TileEngine.exe' becuase it is being used by another process.
The problem appears when I edit the source and then try to Debug.
I've checked using different programs, and the only program using the file is Visual Studio.
If I wait for about 10 minutes before trying to build, it seems to work properly, but when trying different things, it isn't good needing to wait 10 minutes before trying something.
I've tried different solutions both on this site as well as everywhere I can find on Google.
Some solutions I've found, but haven't worked for me
Solution 1 - Using a pre-build script
In some different questions here on Stackoverflow, I've found one solution being that you go into Project Properties > Build Events and then in the Pre-build event command line add:
if exist "$(TargetPath).locked" del "$(TargetPath).locked"
if not exist "$(TargetPath).locked" move "$(TargetPath)" "$(TargetPath).locked"
This made it possible for me to build the project one more time than I usually could, but when editing the code again, and then building, the same error appeared.
Note: Trying to build a release instead of a debug build seems to break the pre-build script and it exits with the code '1', which seems to make VS unable to build properly. Removing the pre-build script makes it work like "normal" again, still with the same error though.
Solution 2 - Running Visual Studio as Administrator
This is another solution I've found, but havent worked either for me, so I assume that Visual Studio already have all the permissions required and running as Administrator doesn't actually make any difference.
Solution 3 - Changing the AssemblyVersion
In this question, Visual Studio build fails: unable to copy exe-file from obj\debug to bin\debug, I found another solution that included changing the AssemblyVersion, in the Properties\AssemblyInfo.cs file, to "2.0.0.0".
This, however, haven't made any difference whatsoever for me.
Solution 4 - Closing UserControl designers before building
According to some different answers here and there on the Internet, Visual Studio apparently uses the built project executable to render the UserControl designer(?). In my case, this is probably not it, though, since I use XNA mostly and it doesn't use the UserControl designer.
Solution 5 - Cleaning up resources when application quits
This might be a solution that I have failed to implement properly. I'm just thinking though, that if this is the solution, how come I haven't been required to do it before. I assume XNA unloads everything that gets loaded through the Content pipeline, therefore this solution wouldn't' make any real sense.
If there is anyone that is able to spread some light on this issue, it would be really awesome, as it is stopping me from programming anything really, because I don't like waiting for 10 minutes because I've made a 2 second change all the time.
I've run into this problem a few times myself.
Mine might not be from the same cause as yours, but I'll tell you what went wrong with me and how I fixed it, hopefully it'll be helpful to you.
Basically, my program never fully exited properly, even when it appeared to. It would continue to run, and thus continue to lock down the file.
A quick dirty fix I used initially (and a way to prove if this is the case) is:
Open Task Manager (Ctrl-Alt-Del)
Click Processes tab
Look for your program's name (TileEngine.exe)
Note: There will probably be name_vshost.exe (TileEngine_vshost.exe) That's a VisualStudio thing, ignore that, it's not relevant.
If you find it, it means your program hasn't actual exited fully.
If it's there, click on it and press "End Process"
So if it's there, then for some reason, your program didn't shut down, like mine did.
Often, this is from a thread being launched and forgotten, or an Async task that never completes, or something like that.
Make sure in your OnExiting(..) void function that you kill all running threads.
If your program is still running despite best attempts to close all threads and other blockers, you can use the very dirty bad method:
In OnExiting(...) run the code "System.Diagnostics.Process.GetCurrentProcess().Kill();" - this will taskmanager-style forceshutdown the current process... this is only as an emergency I-can't-make-it-work-any-other-way method.
I think I found the solution myself.
In the Project Properties, "Enable the Visual Studio hosting process" wasn't checked. Checking it seems to have fixed the problems, at least for now.
Got reminded of it from mcmonkey4eva's post. So thanks for that =)
And thanks for the other replied I've got. Stackoverflow is awesome!
Have you checked if any files are being blocked by your firewall? When I switched to the full version of Avast I find I have to disable the File System Shield It loves to remove my executable files when I try to run my visual studio projects.
I had problems when upgrading to VS2012 Professional. (SDK, .Net, Visual C++ Redistributable package)
ENSURE ALL OF THESE ARE COMPATIBLE WITH THE CURRENT VERSION OF VS YOU ARE USING
What I did, was I ended up uninstalling EVERYTHING that was associated with both Visual Studio downloads. If you are able to remove and save your project files elsewhere and then bring them back. Go through all your program files to see if there is anything hidden in the wrong folder and check your C drive.
Which meant downloading and reinstalling (fresh):
I think if you clean out your program files, it should be ok. I wouldn't recommend going into your register unless you are very sure of what you are doing. IF you have already made changes to the register then we'll have a look at that and other options (if this doesn't solve your problem).
Try removing the readonly check from your solution by unchecking at the folder level.
I ran into this problem and in my case was due to having bin included in the solution; as soon as I excluded the bin folder from my solution the problem went away.
Nothing helped, not prebuild commands, neither designers closing, but I figured out a way that helped me, just changing from debug to release and vice-versa releases locked files and you can delete them without closing the IDE.
I regularly get this problem if I switch from Debug to Release and then immediately F5 to compile. Crazy as it sounds, waiting for, say, one minute after switching between modes will prevent this.
If it's locked, the only solution is to close Visual Studio and re-open.
I solved this problem organizing my resources on solution. I noticed this error when I put some images on my application at the same solution folder.
So,
I'd removed all images and resources from app, save without it.
Moved the images to outside Solution folder.
Open the solution and add this images again, using "Import" button at controls.
If you will try this, remember to do with Application Icon, on Project Settings.
Now, everything is working fine for me.
I hope it helps.
You need to disable Windows Indexer as it locks up the file
Follow this Guide how to disable
In my case the problem seem to be caused by the remote debugger. It starts on local machine when you compile with "x64" option. Try to change the project setting (properties/buid) until you reach the final version.
Change Build Platform target from x86 to Any CPU.
This is happening to me very often. When I am working in Visual Studio 2010 and say I make a code change, then build... Both my existing breakpoints become disabled / and or cannot be set and I also cannot set new breakpoints. Does anyone have a solution for this? It is very annoying. So far the only way I have been able to get around this is to restart Visual Studio which can take 5 to 8 minutes to reindex everything or to try rebuilding individual projects in my solution. My solution consists of several DLLs which make up the entire program.
Check that you have the dependencies set correctly in your projects. I know my breakpoints will become disabled if the code is "out of date". If you don't have the dependencies set up right, then when the updated code is rebuilt it will not rebuild all of the related code which will then leave those modules "out of date".
Since this is VS 2010, the dependencies are on the project not on the solution (you can add solution dependencies, but project dependencies will carry over into a new solution so it is the better way to go when possible).
This issue is caused when you having your Configuration Manager settings set to Release rather than Debug.
In Visual Studios select Build from the menu, then Configuration Manager.
In the next dialog select your project, then locate the drop down menu near the top left corner titled "Active solution configuration:" Make sure it is set to Debug.
That should fix the problem.
As it turns out the post.build file contained numerous conditions for whether or not it should copy several DLLs to a target directory... Since I didn't have time to pick through the xml for these actions I just used a bash script to copy the files after building. No need to get complicated... Otherwise, the formal solution involves setting conditions for allowing the DLLs to be overwritten/copied after compile or not.
I find the Visual Studio post.build file concept a little excessive since in the end it will make little difference whether a dll is overwritten with a freshly compiled version, yet, if you make code changes, compile, and it doesn't copy to the target directory you end up running your app with an out of date DLL and you are not testing with the recent code change..! Others have even implemented the post.build file complete with xml and goto statements...! Leave it to Microsoft to complicate the build & debug process...
Alternatively, if your code is under version control start afresh by checking out the head revision, do another clean and rebuild and start debugging again.
This for whatever reason enabled me to insert breakpoints in my VS 2010 C# project once again, whereas no amount of fannying around with properties, configurations etc got rid of my phantom breakpoint problem.
The best solution I found for this was to quit my Windows job and get another job as a Mac Developer where we use Xcode.! What a huge difference.! I sure haven't seen that breakpoints problem again.!
I've been working on a simple project that uses some common .NET classes, isolated storage, some resources and no external libraries.
Somehow the EXE generated (either in debug or release mode) no longer runs (stops working as soon as it's opened) without giving any details or displaying any exceptions.
It runs normally in visual studio, and there's a .application in the same folder that when clicked starts in install process.
I'm not interested in installation files, I just want it to be the way it was: running an EXE (it's easier to get testers when all you have to do is running it).
I have previous versions of the program, and all of them run normally through the EXE's.
I don't recall changing anything regarding framework, deployment or build. I revised it and there's nothing changed apart from using new objects from the .NET framework.
--[Update]--
Just checked the event viewer. Event data "not available" and answer "not available".
This is a classic example of when a personal version control system would have helped. It would have automatically kept every version of your code including the one right before you made the change that messed up your exe.
Anyway to fix your issue comment out the majority of the code untill it atleast runs. Add a simple output statement just to make sure it is doing something. Then slowly add back in more code.
I suggest you to run your exe file in a consol (cmd.exe) to see if your application displays errors or exceptions in it.
Check the <YourAppName>.Exe.Config file.
Probably it is not well-formed Xml.
I'd start with removing the setup project from the solution, rebuilding then run it in debug mode.
I'm working in VS 2008 and have three projects in one solution. I'm debugging by attaching to a .net process invoked by a third party app (SalesLogix, a CRM app).
Once it has attached to the process and I attempt to set a breakpoint in one of the projects, it doesn't set a breakpoint in that file. It actually switches the current tab to another file in another project and sets a breakpoint in that document. If the file isn't open, it even goes so far as to open it for me. I can't explain this. I've got no clue. Anyone seen such odd behavior? I wouldn't believe it if I wasn't seeing it myself.
A little more info: if I set a breakpoint before attaching, it shows the "red dot" and says no symbols loaded...no problem...I expect that. When I attach and invoke my .net code from SalesLogix and switch back to VS, my breakpoint is completely gone (not even a warning that the source doesn't match the debug file). When I attempt to manually load the debug file, then I get a message that the symbol file does not match the module. The .pdb and the .dll are timestamped the same, so I'm stumped.
Anyone have any ideas?
Thx,
Jeff
I saw this functionality in older versions of VS.Net (2003 I think). It may still exist in current versions, but I haven't encountered it. Seems that files with the same name, even in different directories confuse VS.Net, and it ends up setting a break point in a file with the same name. May only happen if the classes in the file both have the same name also. So much for namespaces I guess.
You also may want to check your build configuration to make sure that all the projects are in fact building in debug mode. I know I've been caught a couple times when the configuration got changed somehow for the solution, and some projects weren't compiling in debug mode.
Kibbee, you were right! It was two files with the same name in different folders. I was setting the breakpoint in the correct file on line 58 - it was putting the breakpoint on the other file at line 58. I was finally able to set a breakpoint by using the "Debug-->New Breakpoint-->Break at Function Name" menu option and entering my function name. It stopped exactly like it should have then.
I agree - so much for namespaces, right? Damn thing cost me a couple of hours. Oh, well...at least it's solved and I know why.
Thx for the answer and thx to Matt for his reply, too!