I need some help. I have put in dozens of hours into a VB.NET project, it has been built in release mode and distributed. Now I have to make some changes to it, and I am unable to debug it properly. My code changes result in behavior where my code is not even recognized.
Also, I installed Visual Studio 2013 recently (moving from 2010), but this project behaves the same in both environments.
I believe that my code has become 'optimized'. The error window tells me that code is being skipped over, and that my code is optimized and JIT is checked.
I have turned off JIT, and I have tried everything to make this project work again that I could think of. I am desperately wanting to know how I can get this project to be in a state where it will debug each line of code again when I make changes.
I can even purposely write bad code, and the debugger does not see it.
This project is now in debug mode, not release. I have checked and followed threads on every thing that other people have done to solve this issue, but nothing works for me.
Either my project launches and works properly as it is coded, or if I change any code only the form launches with no code being run - at all.
please help.
I finally figured it out. The applications that I was struggling with were all built in Visual Studio 2010 on Windows 10. I was trying to work with these in Visual Studio 2013 on Windows 7.
Once I tried to work with them on Windows 10 (visual Studio 2013 this time), they started working and debugging just fine.
I think it may have been DLL assembly paths? Took me more than a week, but I figured out my issue by moving from Win7x64 to Win10x64.
Related
I have a problem with visual studio 2022. I am creating a WPF app in vs 2022 version 17.2.4 using .NET 7 Preview. When I build the solution or press Start Debugging or Start Without Debugging, Visual studio won't update the compiled code(Won't replace binary files with the latest ones) and the behavior of the program won't change to correspond to the code. The problem does not persist when I press Build->Clean Solution and then Build->Build Solution. It does the same whether I build the solution with the debug or release configuration. I tried it with other solutions as well and the problem will not go away. So I know how to deal with this, but it seems weird and annoying nonetheless. It's the first time that I encounter something like this.
P.S.(Yes the solution compiles with no errors or warnings)
I am working on a c# code for the last couple of weeks and I debug it very often.
VS 2019 was working properly but suddenly it got very slow and laggy when I tried to debug my code.
I checked all resources on my machine. All seem as before and are available enough.
Even I checked the same IDE with other codes. All runs and debugs fast enough as before.
I also updated my IDE to the last version (currently 16.8.5 by the end of February 2021).
Did anybody has the same experience with the VS2019 ever?
Thanks in advance.
Not sure whether the issue is caused your code with IDE environment together. Please try the following suggestions:
1) disable any third party installed extensions under Extensions-->Manage Extensions-->Installed to check whether an extension caused that.
2) reset settings under Tools-->Import and Export Settings-->Reset all settings and you can also make a backup of the settings
3) close VS, delete all files under C:\Users\xxx\AppData\Local\Microsoft\VisualStudio\16.0_xxx\ComponentModelCache
and also delete .vs hidden folder under your solution folder, bin and obj folder.
4) type devenv /safemode under Developer Command Prompt for VS to start a pure VS and then try your project.
5) create a new project with your same code and check if this works.
Besides, if all do not help, you could try a small reproducible sample with us.
If debugging suddenly becomes slow, you might consider checking your symbol settings and debugging settings. If you for example enable .NET framework source stepping, debugging can be slow, or if you do not cache symbols or disable for example Just My Code or enable other stuff, like IntelliTrace or install a bad extension.
It might not be an alternative for you, but I am pleased to inform you that I have been using Visual Studio 2022 and it is radically faster. Yes, this is not opinionated, this is an observation. It IS faster. Maybe it is because I do not have many extensions on it, but it is also a 64-bit application with less memory pressure on the GC. So you can first check your settings and then give VS 2022 Preview versions for a spin. I have used it for months and the amount of bugs are rather small if you do typically development. For a Preview version, I am impressed with what they are working for nextgen Visual Studio.
You should also clean your solution and delete and bin and obj folders via for example Powershell script to make sure your binaries are updated. Then rebuild.
If you have "live share" extension enabled, perhaps can try to disable / uninstall that. This one was causing my problem.
Ok, #Mr Qian no 3 did the trick for me.
Situation: After a "Cleanup" (Microsoft Visual Studio\Installer\InstallCleanup.exe) my VS2019 was partially gone. Good tool. :-(
After (re)install, I had 2 folders "ComponentModelCache" over 2 folders of 16.0_xxx : 16.0_4f678462 and 16.0_119826cb
I renamed both "ComponentModelCache" folders (you can delete later, when it has effect)
Build ran as never before...
Thank you, Mr Qian
My problems started as I upgraded to Visual Studio 2022 (from 2019) and upgraded to Windows 11 (naughty naughty, two major changes).
Turns out Windows Defender didn't preserve my exceptions. Using this PowerShell script as a template saved a bit of time:
https://gist.github.com/Braytiner/be2497d1a06f5a9d943dc7760693d460
Performance is back to where is was pre my Windows 11/Visual Studio 2022 upgrade.
Visual studio 2019 (16.8.5) has this problem in debugging. I have updated it into 16.11.8 and it works properly.
we virtualized our build server and having issues building some c++ projects.
It is a win7 (we have some vb6 projects) with visual studio 2017.
When I build a project it just errors out with "This operation may only take place in the UI thread".
Also it is completely random...sometimes it compiles, sometimes it does not.
I have no idea why and what I could try to fix it. I have also a Win10 build machine where the problem does not happen. We want to stick with the Win7 build machine though, because on the Win10 one we got issues with some vb6 projects.
If I use msbuild it works fine, I would rather not replace all devenv calls for now though.
Anyone an idea what the issue could be or how to debug it?
Seems to be an issue with Visual Studio 2017 15.6.x. works fine with 15.5.7
I've got a solution containing a mixture of C# and F# projects (it's a Silverlight app). When I attempt to compile it in Visual Studio 2010 SP1, the build process hangs on one of the F# projects. If I remove that project, it hangs on a different F# project.
The F# compiler (fsc.exe) isn't running, and I can't find any likely-looking process to kill (other than devenv.exe).
It compiles fine on the command line, using MSBuild. It compiles fine in VS11 beta. We can't (yet) migrate the solution to VS11.
This occurs on my PC, and one other PC. None of the other team members have this problem.
Has anyone seen this behaviour before? How do I go about debugging this?
It may be useful to go to Tools\Options\Projects&Solutions\Build&Run and change MSBuild output verbosity to 'diagnostic' and then check the output window to see exactly where things are getting hung, that may help diagnose.
Occasionally during debugging the debugger skips forward randomly. Sometimes I Step into a function inside of another function and instead of going to the next line it skips through to a seemly random place in the future. sometimes to a line partway through another function.
It always seems to respect breakpoints though, i.e. if a breakpoint is set in the future it never will skip past it.
I'm running 64 bit Win 7 and visual studio 2010 ultimate. I'm not using threads. This never happened for me in visual studio 2008. How can I fix this?
Do you have optimizations turned on? If the program is highly optimized, the order of execution can be thrown off, and things can be expanded or rearranged in ways that are not always clear.
I'm running into similar problems debugging a C# program with Visual Studio 2010 on an XP machine. The debugger just randomly skips to some other line or the next break point.
It seems that Microsoft has released a Fix for this in the SP1.
Are you sure that the assembly your code calls has debug symbols? You maybe referencing a dll that was compiled in release mode.
This can happen when the debugger is running against pdb files that don't match the source code you are looking at. Make sure the bin (or where you are running from) is up to date and was built from the same source code you are running in the debugger.
Are you using threads or background workers? When debugging I believe that all threads are paused so it could be switching between them. Otherwise you may have out of date debugging information, Delete your bin and obj directories and do a clean build.
This can also happen when your Debug solution configuration is up to date, but you try to debug the program in Release configuration (if that is not also up-to-date)... or vice versa.
You can switch back and forth between running in Debug or Release configuration using the drop-down next to the green 'play' arrow at the top of the screen.
I had a similar problem in Visual C++ 2008 on Windows 7 32-bit recently. Several minutes before the problem first appeared, a system dialog window “VC.exe encountered a problem and needs to quit” was displayed but the Visual C++ window seemed to survive.
After the problem first appeared, I tried several ways to getting it back to work like rebuilding the solution or restarting Visual Studio. However, it continued to behave strange: It failed to link with an object file I hadn’t touched for weeks, displayed “The breakpoint will not currently be hit. The source code is different from the original version.” etc.
Nothing helped until I rebooted the computer and finally rebuilt the solution (twice, actually).
Click Rebuild Solution.