So my Visual Studio 2010 is extremely slow (and sometimes freezes) when I have a particular file open and attempt to compile and run the project. I have to open the Task Manager and kill the process for Visual Studio to regain control. If I close this file, and open any other file in the Solution Explorer in my project, Visual Studio compiles and runs the program just fine. The build succeeds, but Visual Studio just freezes after that. If I attempt to do anything in the IDE, Windows will tell me that Visual Studio is not responding. I've tried commenting out everything but the bare essentials in the file that's causing the freezing, and that didn't work. In order to get my program up and running, I have to close the file and then build the project. Visual Studio will then build and run the program in a timely manner as long as the particular file is not open. This only started a few days ago, and I haven't made any changes to the code that could have done this, nor have I updated or installed anything else onto my computer. Any ideas would be greatly appreciated. Thanks.
I fixed this. What I did was run devenv.exe /log and looked through the log. It had the following warning in it: "The CTM file is out of date and should be deleted and rebuilt, but the file 'C:\ProgramData\Microsoft\VisualStudio\10.0\1033\devenv.CTM' could not be deleted." I went and deleted this file, and it did the trick. Now even with that particular file open, Visual Studio builds and runs the program just fine.
Related
I downloaded visual studio for C# and now my problem is that when I run a program the very first time it runs without issues but the second time after exiting the program it shows this (pressing f5 also does nothing):
I have tried repairing Visual Studio and uninstalling and reinstalling it but that also doesn't work. It happens to other files too like Python files or asp.net files. Anyone know what's going on?
Try setting your project as a StartUp Project.
See this answer for details.
When I start VisualStudio it frezzes on the start screen. But when I start it a second time while the first instance is open the second instance works fine.
It's not that important but what could cause that problem?
Not sure. Sometimes some Visual Studio extensions are locking up Visual Studio.
I think by default Visual Studio tries to update these extensions
that have been installed automatically.
Recently I was trying to run Visual Studio (at Home) and it would freeze if I tried to open a specific project. But I was busy, so I didn't pursue it further and did other things. Then a week or a few days later I tried to run Visual Studio (at home), and it locked up when I ran it. I tried really hard to fix it.
There is a way I don't like where you can delete all or most of the
extensions from the place Visual Studio installs them, but this is
messy, and it is easy to get rid of something you need, and may hard
to get it back where it works correctly again. So I now recommend against this since there is a better solution now, below!
I searched to find a solution, and someone on a Microsoft board I think said to run from a command prompt as Administrator: DEVENV /RESETSETTINGS, I tried that and it didn't work for me. Then I thought, run DEVENV /? to see what I can see, and I saw :
DEVENV /SAFEMODE
So I tried that and it worked! Note: it was still being run from the Visual Studio Developer Prompt as an Administrator.
Visual Studio loaded up correctly, and I was able to look at the
installed extensions.
Eventually I noticed that they all or a lot of them were disabled (probably because of this SAFEMODE parameter), and I noticed that it the most recently updated were at the top of the list. I noticed that a lot of them had been automatically updated by Visual Studio and started Uninstalling a bunch of the more recent ones, and reverted at least one of them, then later uninstalled it. Eventually, after about 6 to 10 uninstalls, I got it to where Visual Studio would load normally, without the /SAFEMODE parameter! Cool!
So I turned off the automatic updates, so this will never happen automatically again. If I load a new extension or update and existing one manually, I should always exit Visual Studio and reload it after not doing too many updates or installing too many extensions to see if these extensions allow Visual Studio to load.
Sometimes an extension will not freeze Visual Studio, but will have errors. The ones that are the big problem are the ones which prevent Visual Studio from loading all the way and freezing it up. But with the above solution, you can eventually, cleanly, uninstall all the latest updates or new installed extensions until you finally get Visual Studio to load normally!
This workaround should be more widely known, so I am putting my solution to it here. Hopefully what I found should help someone else who is in a hurry, without having a lot of time to burn trying to get Visual Studio running again without freezing!
I use Visual Studio Community 2017, and I got this same issue on startup until I stumbled on this solution that deals with some corruption in the .suo file. Before I open Visual Studio for the day, I first delete the .suo file in my project folder, and it starts up just fine.
It's in a folder called .vs next to the .sln file. You may have to go to folder options View and check "Hidden Items" in order to find this folder. Dig down in that folder and you'll find the .suo file. Delete it. When you startup the project in Visual Studio, it will automatically create a new .suo file. So you'll have to do this every time you reopen.
so i was in the middle of making a program, when i decided to try upgrading to vs2015 just because i like the newer UI.
so i opened the .sln in vs2015 test run the program again, and re arrange the ui of my program, but i didnt add or remove anything, or even touched the code.
saved the file, and tried opening it again on my laptop that still on vs2010.
i can open the solution,i can access and edit the code, but i can't open the designer at all, or run the program that i made.
although i can also upgrade the one on my laptop to the newer one, im doing this project with a friend that is also still on vs2010, is there any way to make it compatible again?
Whenever you try to open the project in visual studio 2015 which was basically developed in visual studio 2010 will prompt the window for the make some changes in the .sln file also it shows all changes in the browser.
If you try to open that file which is changed by the VS2015 will not be able to open in VS 2010 but available to open in VS 2012 and on word
I'm building a project in Visual Studio 2010 and the build fails because it cannot copy the assemblyname.dll file from obj to bin folder. The exact error message is:
Error 7
Unable to copy file "obj\Debug\AssemblyName.dll" to "bin\AssemblyName.dll". The requested operation cannot be performed on a file with a user-mapped section open.
I think this is because the previous file in bin-folder is not accessible. When I try to delete the file manually, I get an error "The action can't be completed because the file is open in another program". If I try to see what application locks the file with Unlocker, I don't get any results (No Locking handle found).
If I restart Visual Studio, the error goes away but happens again after a build or two. Goes without saying that this is seriously slowing me down. Any advice how to start solving this?
VIsual Studio 2012 on Windows 8. I was receiving the same error message on my project. Restarting Visual Studio or cleaning the obj folder manually did not help. Finally I closed all open files (Windows -> Close All Documents) and the problem went away.
This behavior was due to a newly installed Visual Studio extension called Visual Studio Achievements (http://visualstudiogallery.msdn.microsoft.com/bc7a433b-b594-48d4-bba2-a2f24774d02f)
I noticed that the .pdb file was locked by FxCop (using Unlocker) and I think that the Achievements -extension uses it. After disabling the extension I've no longer got the error mentioned above.
This bug has been fixed in recent versions of the extension (>1.7). It was released as a beta, btw...
This behavior of VS happen very often even on my computer (and on computers of my coworkers).
In my experience it happen more frequently when:
I have some form opened in design when i compile
I stop the execution od the application by pressing the "stop" button
in VS instead of exiting the application
So, closing the form in design before compile, and exiting the application instead of stopping it, somewhat mitigate the issue... but it still happen :-|
My computer is Win 7 x64 SP1 with VS 2010 SP1, 8Gb ram, and no swap file
Platform: Windows 8 Pro, Visual Studio 2012
I found that I receive this error when I am accessing the folder in Windows Explorer.
I was creating PDF documents with Visual Studio 2012. To review the sample document I would right click in Solution Explorer and use Open Folder in File Explorer.
On Windows 7 I would get a SYSTEM.IO error if the actual PDF document was open in Adobe Reader which is expected. With Windows 8 I found that I receive the above error if I have the folder open. I suspect there is a conflict with the Windows 8 preview.
If I close the folder and run the program it works fine.
Check if you open the dll in visual studio.
I open the dll in visual studio and this error happen!!
I am using Visual Studio 2005.I am running my code in Debug mode only.But my break point is
not being hit.
I followed :
Cleared my solution and created the one again
Closed the VS and Opened it again
Restarted my PC and tested the break point
But i am unable to figure out the problem.
My Question is:
Is it due to any virus ?
Add-on feature in my IE 8.0 prevents this
My VS is Corrupted ?
I am having botn VS 2008 and VS 2005 installed in my machine so any version
conflicts?
Suggestion is needed.
It sounds like the problem you are having may be due to the source code and the .pdb files being out of sync with each other.
Try these steps:
Perform a "Clean" build in Visual Studio.
Shut down Visual Studio.
Delete any "bin" and "obj" folders in all of your project folders.
Delete the solution .suo file
Sometimes the solution .suo file can become corrupt (doesn't cause Visual Studio to indicate any errors, but usually leads to strange behavior). Nine out of ten times, deleting the .suo file clears any strange behavior in Visual Studio.
The trick about deleting the "obj" folders forces Visual Studio to truely do a clean build the next time it compiles. Doing a "clean" build in Visual Studio only deletes the compiled binary results, it doesn't remove any intermediate object files that may have been created that Visual Studio might be linking against. By manually deleting the "obj" folders, you delete those cached object files and force a true rebuild.
What kind of project is it (website, console app, ...) Are you running the project directly from visual studio, or attaching to it afterwards?
Usually when this happens to me, its because the assemblies that are being used to run the process I want to debug do not match the currently built assemblies from visual studio.
You mention IE8, so if this is a website, you should try to attach visual studio to the w3wp.exe process. Otherwise the breakpoint won't have any effect. Alternatively, run the website using visual studio.
If you hover over the breakpoint in Visual Studio, does it indicate an error? Common problems are that the code hasn't been built, or the DLL that contains the code isn't loaded into the debugged process.