My installation of Visual Studio was fine previously, but has started acting weird lately. Some of the symptoms include
Visual Studio randomly hangs or crashes
Visual Studio won't start
Intellisense disappears sometimes
Plugins are not working, or are failing to start
I can't install or uninstall tools
I can't connect to source control anymore
Certain known good project types fail to load properly
Known file types don't have syntax highlighting anymore
I can't add files to a solution because the option is greyed out
I can't add, remove, or update files to a solution due to an error
I can't add or remove projects to a solution due to an error
I can't open a solution due to an error
The debugger cannot launch, or attach to processes
I can't find any templates when I try to add a new item
I can't copy/paste due to an error
A DLL required by Visual Studio is missing or corrupt
Menus are suddenly empty
Something that I know should normally work, now does not work
How can I fix this?
(This question is meant to be a canonical close dupe for these types of questions)
Visual Studio is pretty reliable, and most of us using it aren't experiencing the issues you are. It's a pretty large and complex suite of components, though, which means problems are bound to occur.
First: Restart Visual Studio and, if that fails, restart your computer
The majority of small issues are fixed by restarting Visual Studio. Some of the ones involving connectivity or services can be fixed by restarting your computer.
If this doesn't fix your problem
There's no way to guarantee that something bad won't happen to a particular installation of Visual Studio. The ways a large, complex application can become misconfigured or damaged are too varied to mention.
The effort it would take to diagnose and track down every possible cause is great. Ain't nobody got time for that. The one reliable solution—which works almost every time it's tried—is:
Reinstall Visual Studio.
Go ahead, rest your eyes for a little bit. Come back when you've come to terms with this sad fact.
…
Resigned? Okay. We're going to go through the steps to fix your problem, starting with the lowest impact, but probably least likely to work, one first. While you are attempting to fix this, keep notes! Mentally, or write them down. If you get to the last step, you'll need them.
First, let's go the easiest route and return Visual Studio to its original state. We can do this by removing all extensions and by resetting all settings.
Open the "Extensions and Updates" dialog. If you can't find it, type that into the quick launch. If you can't find that, try ctrl-q. For each installed extension, highlight it and click the Uninstall button.
Next, let's reset those settings. Make sure you export them first!
From the docs:
To export your settings
1. On the menu bar, choose Tools, Import and Export Settings. Choose the Export selected environment settings option button, and then
choose the Next button.
2. Make sure that the check boxes for the kinds of settings that you want to export are selected and all other check boxes are cleared, and
then choose the Next button.
3. (Optional) Name your settings file, enter a different path where it should be saved, or both. By default, setting files are named
Currentsettings.vssettings and saved to %USERPROFILE%\Documents\Visual
Studio 2015\Settings.
4. Choose the Finish button.
You can import them later from the same location. Now, once you've saved your settings, go back and reset them.
Tools -> Import and Export Settings... -> Reset all settings
Having reset everything, try to repro your issue. Still breaking?
Heck.
There's no doubt that you need to reinstall. Let's go the easiest route and do a repair. Do the following:
Go to Control Panel > Programs > Programs and Features
Select Microsoft Visual Studio [whatever edition] [whatever year]
Click "Change"
Click "Repair"
After you've done this, try to repro your issue. Did it still happen?
Damnit, sorry.
If you want to try a different way, you may be able to do an "overlay" reinstall. Simply run the installer directly and select "install" (if this option is available to you). You can use your original media, but I'd strongly suggest you re-download the installer. This will overlay a new version over the old, without messing up your settings. After reinstalling, try to repro. Did it?
Aw hell. Here we go.
You need to try uninstalling/reinstalling. First, though, you might want to export your settings. You should have done this for step one of this answer, but if you didn't, go back and follow the instructions to do it now.
After saving them, repeat steps 1 and 2 (from the repair instructions) and this time select "Uninstall" instead of "Change". If your issue has to do with an external component, search for it in the list of other installed applications and uninstall it as well. If you're paranoid, uninstall everything Visual Studio related. They may be out to destroy you.
Now, reinstall Visual Studio. If you've found yourself at this point, you're in deep, so don't risk installing from your original media. Download a fresh, fully updated copy from where you originally got it. For example, if you got Visual Studio via your MSDN subscription, go there and download the ISO.
Now, having reinstalled everything, try to repro. Did it happen again?
F##&ing s#!t.
Now is the time to create a bug report. Go to Connect
https://connect.microsoft.com/VisualStudio/feedback/LoadSubmitFeedbackForm
Provide as much information as possible. You need to give them all the info they ask for in the form, plus details about the bug, how to repro it, and what you did to try and fix it. Remember those notes I told you to write down? Bust them out now. I'd strongly recommend you mark your issue public, as it may be found and commented on by others with your problem.
Within a day you'll get a response. They will probably want you to turn on Visual Studio logging and repro the issue. I won't tell you how to do this here, as they will give you exact instructions for the version of Visual Studio you are running. Follow them and reply as soon as you can.
There will be one of three outcomes from this process:
They will tell you that you're doing it wrong
They will discover an outside actor causing the issue
They will discover a bug
For #1, stop doing that, and you're done. For #2, they'll probably tell you to uninstall the bad actor (e.g., remove a plugin) and go tell the people responsible about the bug (don't slack--do it). For #3, they'll triage the bug and it will be fixed sometime later. It's likely they will suggest workarounds that will at least get you moving again, if it's a true bug.
And that's it. Now, go forth and reinstall Visual Studio!
I'm very new to Visual Studio and Universal Windows Apps Development. As a part of the course, I have this codeSHOW project provided.
I've cloned it successfully in VS 2015, but I can't run the project using the .sln file. Error:
Here's the error log: http://pastebin.com/c012Bba4
I have no clue how to fix it, and the issues on github go unanswered so I can't expect much from there.
This is an known issue in Visual Studio 2015.
The problem is with files with the exact same name under different folders in a Shared project, which in your case is "resources.resjson".
The only workarounds are either to make the file names unique and if that is not an option, to duplicate the files in the projects instead of sharing them out of the Shared project.
This is a VS2015 specific bug, the solution loads just fine on VS2013. You can get some insight into what is going wrong. First note that your got two message boxes that announced this error. Barely visible in your screenshot.
The failure.txt file gives more hints, you can see the stack traces of the two AggregateException that are raised when the solution is loaded. You'll see that two tasks are trying to load the same resources.resjon project item. Not correct of course, quacks like a standard concurrency bug.
Nothing actually goes wrong, Visual Studio can handle the exception and declares it "Recoverable", the projects are still loaded correctly. And compile just fine. Only other thing you need is the Bing Maps SDK, you can download the correct version here.
If you have VS2013 then prefer that version, it doesn't have this bug and loads the solution without any complaint. And minimizes the odds that you'll run into other quirky problems. Given the current stability of VS2015, not great, it is the best way to avoid losing time. Otherwise just ignore the mishap and close the message boxes, some future Update will no doubt fix the bug. You can report it at connect.microsoft.com if you wish. Not actually necessary I think, it looks like VS is phoning home.
I would like to debug a same C# console project from two different instances of Visual Studio to increase my productivity, as the edit-and-continue mode is not always enough, to say the least.
I have no problem opening the solution twice, and debugging different projects concurrently, but when I try debugging the same project twice, it expectedly fails as it cannot replace the executables in the bin folders.
The possibility to debug twice from the same instance of the IDE as explained here is very welcome, but not good enough for me as I want to be able to completely edit my code when needed.
Is there any simple way to achieve this? Thanks!
Instead of clicking Debug or hitting F5, open a command prompt and start the number of instances you want from there. Now start as few or as many Visual Studio instances you want and go to the debug -> Attach... window.
In the Attach to process window, find the instance youw ant to debug and choose attach. This will allow you to attach to as many instances of your applciation as you'd want.
Now, if you want to be able to edit these application son the fly and spin up new instances, that isn't possible because, as you've found out, the executable will eb in use. Short of creating multuiple copies of your output directory and always starting a copy, never the original, you have no way to achieve that.
Just as a note for whoever stumbles upon this page, as it's ranked very high on Google:
If you want to debug two instances of the same program in Visual Studio, this is as simple as opening up two instances of visual studio and pressing f5 in each instance. This works remarkably well, although you want to wait until one program is up and running before you start the second - otherwise you may get conflicts in your bin folder (which is what it seems OP didn't do.)
When I debug my project, I get following error:
"Unable to copy file "obj\Debug\My Dream.exe" to "bin\Debug\My Dream.exe". The process cannot access the file 'bin\Debug\My Dream.exe' because it is being used by another process."
Using Process Explorer, I see that MyApplication.exe was out but System process still uses it although I stopped debug before.
Whenever I change my code and start debug it is going to happen. If I copy project to USB and debug, it runs OK.
Why? How can I fix this error?
I use Window 7 Professional. With Xp I have never got this error.
Ugh, this is an old problem, something that still pops up in Visual Studio once in a while. It's bitten me a couple of times and I've lost hours restarting and fighting with VS. I'm sure it's been discussed here on SO more than once. It's also been talked about on the MSDN forums. There isn't an actual solution, but there are a couple of workarounds. Start researching here.
What's happening is that VS is acquiring a lock on a file and then not releasing it. Ironically, that lock prevents VS itself from deleting the file so that it can recreate it when you rebuild the application. The only apparent solution is to close and restart VS so that it will release the lock on the file.
My original workaround was opening up the bin/Debug folder and renaming the executable. You can't delete it if it's locked, but you can rename it. So you can just add a number to the end or something, which allows you to keep working without having to close all of your windows and wait for VS to restart. Some people have even automated this using a pre-build event to append a random string to the end of the old output filename. Yes, this is a giant hack, but this problem gets so frustrating and debilitating that you'll do anything.
I've later learned, after a bit more experimentation, that the problem seems to only crop up when you build the project with one of the designers open. So, the solution that has worked for me long term and prevented me from ever dealing with one of those silly errors again is making sure that I always close all designer windows before building a WinForms project. Yes, this too is somewhat inconvenient, but it sure beats the pants off having to restart VS twice an hour or more.
I assume this applies to WPF, too, although I don't use it and haven't personally experienced the problem there.
I also haven't yet tried reproducing it on VS 2012 RC. I don't know if it's been fixed there yet or not. But my experience so far has been that it still manages to pop up even after Microsoft has claimed to have fixed it. It's still there in VS 2010 SP1. I'm not saying their programmers are idiots who don't know what they're doing, of course. I figure there are just multiple causes for the bug and/or that it's very difficult to reproduce reliably in a laboratory. That's the same reason I haven't personally filed any bug reports on it (although I've +1'ed other peoples), because I can't seem to reliably reproduce it, rather like the Abominable Snowman.
<end rant that is directed at no one in particular>
I've had this error crop up on me before, even in Visual Studio 2008. It came back and more prevalent in Visual Studio 2012.
Here is what I do.
Paste this in the troublesome project's pre-build event:
if exist "$(TargetPath).locked" del "$(TargetPath).locked"
if exist "$(TargetPath)" if not exist "$(TargetPath).locked" move "$(TargetPath)" "$(TargetPath).locked"
Computer (right-click) -> manage -> Service & Application -> service -> Enable Application experience
Worked For me!
I had the same issue in Visual Studio 2013. I'm not sure what caused this for my project, but I was able to fix it by cleaning the solution and rebuilding it.
Build > Clean Solution
Build > Rebuild Solution
I understand this is an old question. Unfortunately I was facing the same issue with my .net core 2.0 application in visual studio 2017. So, I thought of sharing the solution which worked for me. Before this solution I had tried the below steps.
Restarted visual studio
Closed all the application
Clean my solution and rebuild
None of the above steps didn't fix the issue.
And then I opened my Task Manager and selected dotnet process and then clicked End task button. Later I opened my Visual Studio and everything was working fine.
At least in my case I've noticed that visual studio 2012 was creating at least two msbuild.exe ghost processes, which did not perish after build. These zombies apparently are causing file locks to appear.
Killing msbuild.exe's is one time solution, it needs to be done per build basis.
But then I've figure out that I could disable parallel build once and for all - went into Tools > Options > Projects and Solutions > Build and Run > "maximum numbers of parallel project builds" - by default it has value of 8, I've switched to 1. Works like charm.
Of course builds are bit slower now, but better safe than sorry.
At least for this particular small project I did not need more than one build thread.
See my answer here if you're having this problem while running unit tests. Answer copied below:
Building upon Sébastien's answer, I added a pre-build step to my test
project to automatically kill any vstest.* executables still
running. The following pre-build command worked for me:
taskkill /f /im vstest.*
exit 0
The exit 0 command is at the end to prevent build failure when there
are no vstest.* executables running.
I solved this problem..
near the debug you see drop down menu with some configuration. Default there was Any CPU. Select x86 and run the program it will work. If x86 not there go to configuration manager and add the x86
Recently I've been in a trouble with Visual Studio 2012 with same error description: "The process cannot access the file because it is being used by another process..."
To fix this first of all you need to understand the application which still use it. I've shutdown all processes like "MSBuild" and "MSBuild host". But this is not enough. If you have installed "Code Contracts" and turned on then it sometimes takes your DLLs for checking and hanging up on this operation.
So, you need to stop all processes of "CCCheck.exe" and that's all.
Finally, to understand that process is using your DLL you always may try to just Delete "obj" folder in your File Manager and this operation will fail, you may see the "Message Window" with description of the hanging operation. Also, as a variant, you can try to use "Sys Internals Suite" application.
Worked for me.
Task Manager -> Name of project -> End task. (i had 3 same processes with my project name);
VS 2013; Win 8;
Make sure that any previous run of the application (for example, start without debugging option) is actually stopped. I was working on a WPF application, started without debugging and had it minimized when I kept getting the error. After closing the application VS behavior got back to normal.
I have been plagued by this issue in Visual Studio 2017. It started about two or three weeks ago, and has severely eaten into my productivity. Clean and Rebulid haven't worked; even restarting my machine doesn't do the job.
One way to deal with the issue is to clean the offending assembly, and to build (as opposed to rebuild) the project you want to run immediately afterwards. This works about 30% of the time.
However, probably the most reliable solution I've found is to open a Developer Command Prompt, and use msbuild directly. I've been doing this for the last three days, and so far the problem hasn't happened once.
In my case was that I have enable "Show All Files".
Visual Studio 2017
Run taskmanager.
Locate netcore and delete it.
You can then delete the file manually or by running Clean.
This is pure speculation, and not an answer.
However, I have been having this problem for a while.
I came after a time to suspect an interaction between VS and my AV precautions.
After some playing, it seems that it may have gone away when I modified my antivirus so that everything under the
C:\Users[username]\AppData\Local\Microsoft\VisualStudio\10.0\ProjectAssemblies
folder was not included in the real-time protection.
It looks as if the build actually writes the DLL here first, then copies it to the final build location.
It could be too late. But, I encountered similar problem and in my case the project had self reference. Hence, deleting it from the References worked like a charm!!!
I've found the quickest way without closing forms or restarting VisualStudio is go to the project's compile page and click "Advanced Compile Options..." button. Then make any change to one of the options (say, changing Generate Debug Info from Full to pdb-only), then click OK.
It works every time and will have to do until MS fixes this bug (I've never had this problem until I switched from VS2012 to VS2013)
Another note, if you can't clean the project or solution, it won't build. The files are definitely locked by VS (not a antivirus problem, at least not in my case)
I tried all these suggestions as well as other suggestions found elsewhere and the only thing that worked for me was restarting my computer. Then I did a clean solution followed by rebuilding. I am using Visual Studio 2013 for reference.
I have run to this same issue, and what I found is there are actually running mulitple Windows form application in the background. It happens when your application has two forms and you close the 2nd form which is not your main form so the application will not totally exited.
I usually run my application
through its exe or
run without debugging
Solution is close the other instance of Windows form application.
This is one way to always close your application instance.
Pre build command
(if exist "$(TargetDir)*old.pdb" del "$(TargetDir)*old.pdb") & (if exist "$(TargetDir)*.pdb" ren "$(TargetDir)*.pdb" *.old.pdb)
Helped
[Solved] Error: Cannot access file bin/Debug/… because it is being used by another process:
I am approaching that you get this error while you was trying to run two windows form one after another such as first loading a form then after sometimes it will automatically disappear and the second form loaded onto the screen.
Basically, you need to close your first form which is running in the background and the main reason behind this error.
To close the first form you have to add these two lines of code in the second form load event handler.
Form1 form = new Form1();
form.Close();
This will solve the error perfectly.
One simple solution is you go to bin\Debug folder, delete all the files in that folder, then rebuild. If it doesn't work, close Visual Studio then go to bin\Debug folder using file explorer, on the left coner, click on File> Open Command Prompt> Open Command Prompt as Administrator > Enter this command "DEL /F /Q /A *" > then rebuild
i found Cody Gray 's answer partially helpful, in that it did direct me to the real source of my problem which some of you may also be experiencing: visual studio's test execution stays open by default and maintains a lock on the files.
To stop that predominantly useless behaviour, follow the instructions from https://connect.microsoft.com/VisualStudio/feedback/details/771994/vstest-executionengine-x86-exe-32-bit-not-closing-vs2012-11-0-50727-1-rtmrel
Uncheck Test menu -> Test Settings -> "Keep Test Execution Engine Running"
My problem was dotnet got hung up and whenever VS would try to make a new dll, or access an old one, the dotnet process would latch onto the dll and stop visual studio from cloning the dll. Solution is just to end all dotnet tasks in task manager(it will only actually remove the dead one, if you are trying to end one and it won't shut down, that means it's working).
Close VisualStudio, ctrl-alt-delete, select Task Manager, find and end all MSBuild processes - VisualStudio basically has a pretty severe bug where it loses control of its debugger and the debugger maintains a lock on the .pdb file in the debug/bin folder. After you end all the MSBuild (debugger) processes, delete the /debug/bin folder and reopen your solution in Visual Studio. You're good to go now. Microsoft needs to fix this crap.
I have opened a separate question regarding VS 2017 that had a similar behavior after one update. The problem seemed to be generated by the antivirus program although.
I have added the bin folder to the antivirus exclude list, restarted the machine and now it seems to work.
I have faced the same issue, but none of the answers above helped me! I just simply closed my Visual Studio 2017 then re-run it, and It worked!
I've tried every answered here and this worked for me
Close your Project.
Stop running tasks in task manager
Restart your pc
Open and build project again
it worked for me.
I got this error because I was running my solution, but not in debug mode. I had forgotten this. I realized it and stopped my solution from running. This cleared up the issue.
Another kludge, ugh, but it's easy and works for me in VS 2013. Click on the project. In the properties panel should be an entry named Project File with a value
(your project name).vbproj
Change the project name - such as adding an -01 to the end. The original .zip file that was locked is still there, but no longer referenced ... so your work can continue. Next time the computer is rebooted, that lock disappears and you can delete the errant file.
On the current project I am working on, there is, at the moment, a large churn of code, which means updating from source control can mean at times many csproj file changes. As we all know, VS2010 doesn't have a "Reload all" button, but you must reload each project and confirm each reload.
Is there a method where either the project is auto-reloaded or the IDE can detect this and ask for a solution reload?
Finally found a solution:
http://lostechies.com/jimmybogard/2011/01/27/reloading-all-projects-with-vscommands/
Quoting from the site:
Quite often I’ll find myself working
in situations where multiple projects
have changed, and Visual Studio asks
to reload them, one at a time. This
happens when I’m working a lot with
source control, and doing things like
switching branches, performing merges,
or just integrating upstream changes.
I have to click “Reload” a million
times for each project that changed on
disk, and it’s quite annoying. On top
of that, VS forgets which files I have
open, so every file that I was working
on gets closed.
I may be the last VS user to find out
about this, but a free lite version of
the VSCommands plugin is available on
the Visual Studio Gallery that does
just what I need – reload all changed
projects at once, preserving which
files I had open:
It's a pain, but the best option I've found is to Close the solution before Getting the latest source code.
If there are more than two changed projects, it is faster to manually unload&reload the entire solution than it is to Get and wait for it to unload&reload the affected projects only - reloading projects is achingly slow (even disregarding having to click the OK button for every project that changed).
(In my mind the real question is: Why does it ask that question at all??? If you Get the latest source code, there is absolutely no sane reason why you would want to only use part of it. It's like a petrol station attendant saying "You've bought some fuel. Would you like me to now actually put it in your car, or shall I just pour it out on the ground?")
Well, that doesn't work if your references paths changed in the csproj file and your using something like the sysinternals junction tool to change a symlink. E.g. tool switches D:\Projects symlink from D:\Baselines\1.0\Prjects to D:\Baselines\2.0\Projects , and because someone changed the folder structure between 1.0 and 2.0, your .csproj file suddenly points the dll path from ....\References\some.dll to ....\References\3rd-Party\some.dll . I know that is a special case, but happens (e.g. in my company).
There is an alternative solution though, one which I highly recommend as it has other benefits, too: the not-so-well-known VS 2010 Extension Solution Load Manager. It defers loading of Projects to the background, or until manually loaded, improving solution load time a lot for large solution files. It has this "reload solution" button in it's menu (unfortunatlely there seems to be no shortcut) which then reloads all solutions from scratch, skipping/backgroundloading the solutions you set. A Microsoft guy commented on his blog that they wanted to include something similar into VS 2010, but the feature didn't quite make it.
Sure, it may take longer then "just" one click and updating 100 documents, but it solved my problem of (relative) reference path changes, and gives a nice speed boost every time I open an at least medium sized solution.
Edit as of Oct 2013
VS2012 includes this functionality by default. At least the async loading stuff. The "don't load at all" functionality is unfortunately only possible by using manual "unload project" in VS2012. But as pr-project memory consumption did go down with VS2012, it's not that big of a deal anymore.
If you have checked the option "detect when file is changed outside the environment" in the "Documents" section of options, projects and files are reloaded when changed. It works for me when switching branches in git.