Iv'e had that problem for long time and then I found the solution of disabling visual studio hosting process or enabling native code debugging every time in the properties of the project,but its been really annoying and I don't even know if I need those functions and dose it hurt my projects so I want to know if there is a solution without doing it every new project and will not have negative effect on my projects,using Visual studio 2012 express and win7 64bit.
thank you for the help.
Related
hoping someone can help me. Recently my Visual Studio 2015 started to take a very long time when it encounters unhandled exception - full 20 seconds before debugger breaks and shows me where the problem is. I tried cleaning up cache, user folders, completely reinstalling visual studio, different runtime (I was using dot.net 4.6.2) with no luck. I am using VS 2015 ultimate on windows 10, running WPF project targeting 4.6.2 (I tried a very simple project with just one button to make sure it's not my solution and got same result). When this happens, Visual Studio is not responsive. Any ideas are greatly appreciated - planning to wipe my computer clean because not sure what else I can try. Thank you
The answer in my case was definitely exception assistant. Having that option turned on slows down entering break mode in Visual Studio. I found out in my case that toggling the exception off and back on improved VS breaking from 9 seconds to 2 seconds (very odd - I blame VS for it). I got to say that if I have many exceptions, I would turn this feature off, otherwise this really is a very useful dialog.
I use unmanaged dll with P/Invoke in this app, and I always tested it inside Visual Studio (with debug mode on x86 CPU because the dlls are only x86), and it works just fine. But when I just start the exe manually after some time (probably at the first operation with those dlls, but I don't know exactly) it says the exe has stopped working, and it starts checking for solution (I use Visual Studio 2013 on Windows 8.1, if that matters). I tried to add the dlls to the project as existing item, but that doesn't help. Also I know, that it's not because it can't find those dlls, cause if I delete them, it doesn't crash, just freeze without any error message. Shouldn't it work the same from Visual Studio as manually started?
There is also a weird bug when I run from Visual Studio: everything's work fine, but sometimes Visual Studio just suddenly stops debugging, as if the program were closed and the GUI of my app freezes, and I can only close it by closing Visual Studio (as I close it, the GUI disappears). Maybe it's a totally different problem, but it can be connected.
Edit:
Here's the project on github, if somebody could check it:
https://github.com/geiszla/CycriptGUI
Some news: If I run it with Ctrl+F5 it also crashes. What's the difference between F5 and Ctrl+F5, that can cause this problem?
Searched all over Google with no real simple answers. Here it is folks(at least it worked for me and is simple):
When you run the console app in Visual Studio, look at the output window at the bottom, get the location of the ..\bin\Debug\*.exe
Copy the *.exe and the *.config to your desired folder, run it, it should work the same way in Visual Studio.
Thanks for every help, my problem was solved: I called an unmanaged function with only 2 parameters, while it had 3. However I still don't understand why it worked with debugging mode, and not without debugging.
When i tried to created a WPF application it gets stuck on "Creating Project" and an error message occasionally pops up
"
Microsoft Visual Studio Express 2013 for windows desktop is waiting for an internal operation to complete. if you regularly encounter this delay during normal usage, please report this problem to Microsoft."
I've tried to search for answers and disable my antivirus but to no avail. Would appreciate any help.
I had the same problem while working on an ASP.NET project; the only thing that worked for me was building a new project and copying and pasting the code.
(It took a really long time to build the new project for some reason.)
Restart your VS and/or your PC. VS 2013 is incredibly faster than 2010 but still has many bugs.
I had Visual Studio 2010 installed on my Windows 7 desktop, that I was using primarily to debug ASP.NET solutions. Everything was working great, until one of the Windows updates installed a new version of the .NET Framework. Now I get the following message when I try to place a breakpoint and then do a "debugger step" in my C# code:
To make matters worse, it doesn't happen all the time. I tried to find any pattern, but the best way I can describe it is sporadic.
Any idea how to fix this?
I just got this in Visual Studio 2015. I was debugging on a separate thread, hit the breakpoint but could not continue. A reboot did not fix it.
I deleted all of my breakpoints, reset the two that I actually wanted and it works!
Can I suggest you try using the resharper test runner. I have also been hitting this error a lot in VS2017 15.5.2 I have found its something to do with the VS test system.
Even though this solution is a product recommendation (I don't work there) it solved my issue and I was able to get things debugged.
I'm working on a VS2010 Solution containing an ASP.NET Website Project and 8 c# class libraries. All projects are set to compile under .NET 3.5
When I set a breakpoint somewhere in the class libraries, the debugger breaks correctly and everything is fine. If I then stop debugging, modify code in the class library, and start debugging again (which of course rebuilds the libraries which were modified) the debugger ignores the breakpoints.
Has anyone else experienced anything like this? I'm lost and it's extremely frustrating to not be able to debug after making even a single line change and rebuilding.
Visual Studio 2010 Ultimate
Windows 7 Professional 64-bit
Be sure that you are killing your webdev server instance. If the breakpoints that are not being hit are in server code a new debug instance won't automatically attach to it.
I encountered this issue - the only way to resolve it was to recreate the solution by importing the existing project into the new solution. Not an ideal workaround but better than googling for an entire day and not being any better off!