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.
Share
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…