Related
Using TFS in Visual Studio 2013, another Team member made many changes to the solution structure (moving files between projects, new projects, new dtsx files, updating most files, consolidating connection managers). After getting latest, whenever I open the solution the Output window now pops up and continuously lists the same error:
TF10121: The path '' is not found or not supported. Type or select a different path.
(this error repeats about once per second)
There is a similar post here for VS 2013 with similar error, though apparently not with the near constant repetition of the error and no help.
Pinning the Output window helps by at least preventing the constant stream of repeating errors from changing the focus while I work.
No change after reinstalling software.
Closing the solution stops the errors. Unloading all the projects stops the errors, but they resume when reloading.
Opening a file in the soln sometimes temporarily halts the errors.
Opening a local solution is fine, adding the solution to source control causes error to start
This seems to be an error with the workspace mappings. It may be that your workspace mapping contains a drive which is no longer available or another issue that breaks the workspace. Possible issues:
Drive no longer available
Inaccessible network drive
Permissions are blocking access to a folder
Your mapping may require you to run with Elevated Privileges.
The target mapping may be empty
From the File -> Source Control and edit the workspace. If editing doesn't solve it, try deleting the workspace completely and creating a new one.
We using VS SSIS 2012, in solution folder I have .vssscc file and it has very short config info. I saw two parameters have empty value like ""
"PROJECT_FILE_RELATIVE_PATH" = ""
"ORIGINAL_PROJECT_FILE_PATH" = ""
So I changed to
"PROJECT_FILE_RELATIVE_PATH" = "."
"ORIGINAL_PROJECT_FILE_PATH" = "."
And seems removed message. As you can see I have no explanation. Just tried and worked for me.
This happen to me in Visual Studio 2017 with a solution that contained a python project. One of the python environments was an old environment I deleted before. Once I removed that environment from the project the repeating error stopped.
I installed VS2013 (v12.0.21005.1) and added ReSharper 8 (v8.0.2000.2660) a day or two ago. That day it was fine. Now I'm lucky if I can get it to open one solution in a whole day. It opens OK by itself, but when I try and open a solution from within - via the menu - it hangs, badly. If I right-click a solution in Windows Explorer and 'open with VS 2013', it opens then hangs, in exactly the same way. Every now and again, for hours, I get a little notice that it's busy with something.
Anyone know what could be wrong, before I endure a reinstall that doesn't fix the problem?
Sometimes it's enough to simply delete the ".v12.suo" file and try to open the solution again. Helped me many times when VS2013 was freezing on loading a project.
Deleting all ".suo" files worked for me. There were several copies due to opening the solution in multiple versions of Visual Studio.
Edit:
Possible path could be:
PathToSolution\.vs\ProjectName\v14\
.vs may be a hidden folder.
.suo is filename.
Basically it could be anything, but you can try a few things:
Turning it off and on again.
Clear the ReSharper cache, it's in %LOCALAPPDATA%\JetBrains\ReSharper\<CurrentVersion>\SolutionCaches, where you should find a folder matching the solution you are trying to open. Just close all instances of VS2013, delete the folder and try again.
turn off ReSharper: Tools > Options > ReSharper > General > Suspend
uninstall ReSharper completely and see if problems persists.
Repair Visual Studio through Programs and Features.
I found the following to be the better approach to debugging VS based on MS Connect instructions
Please help to confirm if your captured dump file is a 32-bit dump file. If it is a 64-bit dump file, please use the following step to capture a new dump file.
Start Visual Studio.
Start another instance of VS.
In the second instance click Tools | Attach to Process...
In the list of processes locate devenv.exe.
Click Select... and explicitly choose 'Native' and 'Managed' code.
Click OK and OK to close Select dialog and Attach to Process dialog.
Go back to the first instance of VS and repro the hang.
Upon the hang, control should go to the second instance of VS. If not please go back to the second instance of VS manually, and hit "Break All".
In the second instance click Debug | Save Dump As Minidump with heap.
If you are running the VB profile you will not see the Save Dump As menu item. To add this menu item:
Select Tools -> Customize
Select the Commands tab
Select Debug from the Menu bar dropdown
Click Add Command...
Select Debug from the Categories list.
Find the Save Dump As entry in the Commands window.
Click OK (the Save Dump As... command is added to the top of the Debug menu).
Click Close
You can get detailed steps about how to get the dump file and call stack at http://blogs.msdn.com/debugger/archive/2009/12/30/what-is-a-dump-and-how-do-i-create-one.aspx
If you find the problem is with Resharper Addin you can then report the issue via - http://youtrack.jetbrains.com/issues/RSRP
Suspending Resharper Worked for me.
Goto
Tools -> Options -> ReSharper -> General -> Suspend Now
Now your solution will load very fast.
After your solution fully loaded, you can change the Resharper settings to Resume Now.
Are you using any node modules in your project? Or can you identify that it is a ReSharper specific issue?
If you've got NPM modules (eg. for Grunt), mark your 'node_modules' folder as 'hidden' (no need to make child folders hidden though), and try again.
Visual Studio was hanging on open for me, turned out it was trying to scan deeply nested node modules with file paths longer than the Windows maximum (260 characters), and this was preventing me from opening the solution in VS, but marking the folder as hidden solved the problem.
I had this issue recently as well, and found that disconnecting my computer from the internet when loading the project fixed it. With this, I managed to cut loading times from several hours down to seconds. Since my network cable is not particularly accessible, I simply disabled my network adapter before loading the project (in Control Panel).
This soon became frustrating, however, and I recently looked into the problem again. It seems that logging on to my Microsoft account in Visual Studio ultimately fixed the problem, and I now have no more issues loading projects.
This may work for you as well (if you haven't yet fixed it - but since there is no accepted answer here, I assume that the problem is persisting), so I suggest that you at least try disconnecting from the internet, even if you would rather not enter your Microsoft credentials.
I went into the %LOCALAPPDATA%\JetBrains\ReSharper\
and opened all the directories looking for the SolutionCaches, and emptied all of them. Problem solved. The application was quite large, so this helped.
Check for Windows updates
I had this problem too. Furthermore, I couldn't open my Windows firewall settings (trying to block VS's internet connection).
When opening update settings (Windows 8), I saw there was a pending update ("found today"), so I rebooted my computer, letting Windows update. After that, VS and the firewall worked fine again.
Check your hardware
I've had the problem a second time; even Windows 8's update page would keep loading forever. It was an issue with my (non-OS) hard drive: https://superuser.com/questions/756261/various-parts-of-windows-8-and-visual-studio-2013-get-blocked-by-possibly-comm?noredirect=1#comment978074_756261
I get this issue now and again - VS 2013 Update 2, Win 8.1, IE 11.
Try this - Open task manger, kill the VS app hanging, and then close any IE sessions that are running in the Background Process list - there may be one or more hanging around.
Restart VS
Seems to clear it for me, without a reboot.
The problem I had was the Perforce connection.
When opening the solution, it would ask if I wanted it to connect to Perforce. Allowing it to try would make it hang and allocate 1.5 GB of RAM.
Not allowing the P4 connection let it load properly (allocating 1 GB RAM). Then I could tell it to connect to P4 after, and it is now fine.
For me , whether computer crashes with power outage, or sometimes with mandatory reboots in the middle of the night. What does WORK for me
DELETE ALL FILES IN THIS DIRECTORY:
C:\Users\yourusername\AppData\Local\Microsoft\WebsiteCache\
For anyone still referring this helped me:
I had to always delete .vs12.suo file to load the project.
I came across this thread from Microsoft and following that I created registry entry which fixed my issue with Solution load.
https://connect.microsoft.com/VisualStudio/feedback/details/860685/visual-studio-hangs-after-10s-when-loading-solution-corrupt-suo
I had similar issue, when i checked the solution file it was created by VS.Net 2012. To resolve the issue, I created dummy solution file and reloaded the projects from vs.net 2012.
Also observed when nuget package update got screwed up, while you reload the solution, Visual Studio might get hang.
The Visual Studio might go hang, when there was a problem in loading the nuget packages.
In my case, VS 2013 Professional was hanging on every startup, even without opening a solution because the license was no longer valid.
Last item in the log file:
<entry>
<record>367</record>
<time>2015/07/13 20:11:05.051</time>
<type>Information</type>
<source>UserConnection</source>
<description>myemailaddrs#gmail.com signed in for IDE user</description>
</entry>
And on the msdn.microsoft.com subscription page: "Your subscription is no longer active, contact your administrator."
I had to get an updated subscription from my employer.
Deleting Test Results from my TestResults folder actually did the trick for me. Just another thing to try.
VS2012 hangs on me e.g. when opening a csproj file on a network share (in fact on a share that was on the VirtualBox host, connected as a smb share using a VirtualBox feature).
Copying the project over to a local drive fixed it for me. Not sure if assigning a drive letter would do the trick.
Also not sure why it does not work via network share, if it is a VS limitation or perhaps some plugin (I use resharper, of course).
For me this appears to have something to do with the project having the MVC 4 project type guid (E3E379DF-F4C6-4180-9B81-6769533ABE47). Removing this guid from the .csproj resolved the hanging for me. (An additional wiping of the .vs folder was required after removing the guid.)
I just removed "packages" folder from root of solution and it helped for me (Visual Studio Express 2015)
Sorry for having to create a new post instead of commenting on the selected answer .. I do not have enough rep to comment at this time.
My issue was was temporarily resolved by the "...delete the .suo file ..." solution, and as other folks pointed out, I had to delete the file every single time.
Since it (apparently) is impossible to stop the creation of the file I started to dig a little more into what the file did. In addition to saving user settings, I believe it is also saving session settings, like which files you have open when VS is closed. I suspected that my project is attempting to open a file that no longer exists and that is what is causing the hang. What fixed things on my end was to delete the .suo, open VS, open a file within my solution, build and close the solution. After doing this I have had no hangs.
tl:dr
In my case, a user setting file(.suo) was attempting to open a file in my solution that no longer existed. I resolved the issue by performing the following steps.
Delete the .suo file (for me this was in /[projectfolder]/.vs/[projectname]/v14
Open Visual Studio
Open your project
Open a file (I simply opened a random .cs file)
Build and save your solution (Simply saving may do the trick, I built by habit)
Close Visual Studio
Hope this helps someone ... we spent way too many hours on this issue :)
Lots of suggestions here and elsewhere but the only thing that permanently worked for me had to do with the start-up project I'd set. This is what I did:
Delete the .suo file as suggested elsewhere.
Start VS and open the solution. All should be well at this point.
Leave the start-up project as-is, even if it's not what you want.
Save the solution. (Possibly do as someone else suggests and open a file, clean, build/re-build, etc, but I didn't have to do any of that.)
Close the solution and exit VS.
Re-start VS and open the solution.
Change the start-up project to whatever it should be
Save the solution. (Possibly again do the open file, clean, build/re-build, etc.)
Close the solution and exit VS.
Restart VS and re-open the solution and all should be well.
This might or might not work for you but I'd tried everything I could find - registry changes, debugging VS from a second VS session, you name it - but nothing else worked for more than a single start/open.
Try to uninstall extensions with "Control Panel" or disable any add-in in [Tools]=>[Add-in Manager] then try to reopen the solution.
My problem was fixed by uninstall "Visual Localizer".
In my case the Fusion log has been enabled. Log files has been growing for months as I forgot to turn it off after investigation. This way the antivirus software started to check these big log files several times during opening the solution, and "Preparing solution..." message is visible for long-long time. When I noticed this, I turned off the fusion log, and problem solved. Solution loads in 10 seconds instead of 20 minutes.
I've had this issue multiple times, in pretty much all versions of VS. The one solution that seems to work most of the times is to delete the .vs folder located in the solution folder. Sometimes it's enough to delete the .sou file located in .vs///
The folder is hidden by the way, so you will have to enable "Show hidden files and folders"
For me the solution was to disable source control (Set plugin to None in Tools->Source Countrol). I think it was trying to sync some huge Git repo for some reason (have a couple of massive repos, but not in the tree I was trying to open).
I have fixed the issue by uninstalling these two plugins:
Productivity Power Tool
Web Essentials
I restored a previous version of the .vbproj file and it solved it.
I don't know what was in the newer version but the problem was something inside the .bvproj file itself.
I have a weird error when I try to create a new solution in vs2010, it started today...
I get this error no matter what kind of solution I create, and in every directory on the disk:
Any idea about the reason I get this message?
I tried to search the error text on google but I only found posts about errors while converting an old solution file which wasn't helpful.
Also tried running vs2010 as administrator, but nothing works, I still get this message
EDIT:
I checked the space left on my disk (26 GB), tried other names for the solution, tried to create a text file in the folder and it works
One of the most common problems is one or more plugins/addons that either fail them self or fail if loaded in combination with other plugins/addons/vsipackages.
To work out if that is true in this case do the following:
start a visual studio 2010 prompt
type devenv /Safemode
Check stabiity of VS2010
Works? unload/remove plugins until you have a stable installation
Doesn't work? Contact MS Support
The msdn documentation on devenv switches
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.
Using Visual Studio 2010 beta, when I run my application within the IDE for debugging, it works perfectly the first time. However, after closing the debug session, either by closing the application or clicking the stop debugging button, all subsequent attempts to debug the application fail with:
Error 1 Unable to copy file "obj\Debug\Application.dll"
to
"bin\Debug\Application.dll".
The process cannot access the file
'bin\Debug\Application.dll'
because it is being used by another
process.
Handle.exe from SysInternals does show handles open, but even if I close the handles, the error doesn't go away. Any attempts to delete the file manually result in an "Access Denied" error message.
To fix this, I have to completely restart Visual Studio, afterwhich the Debug session will work once and stop again.
I'm not entirely sure when this started happening, but I'm pretty sure it's fairly recently.
UPDATE: After I force close the handles on Application.dll, I get the following error from VS:
Error 1 Unable to copy file
"obj\Debug\Application.dll"
to
"bin\Debug\Application.dll".
The requested operation cannot be
performed on a file with a user-mapped
section open.
What the heck is a "user-mapped section"??
UPDATE 2: It appears that this problem occurs when I have a Form open in Design view when trying to debug. I'm going to do some more troubleshooting and then post my results.
UPDATE 3: I think I've narrowed it down to a form using a UserControl.
To be honest with you, it sounds like a bug in VS2010. For some reason it isn't closing the open handles when the debugger stops. Killing the VS process automatically closes those handles, allowing you to access the file again. As a work around, you might look at unlocker it's free and works exceptionally well. I know that's not a great answer, but it should be faster than restarting VS. You might to consider sending a bug report too...
Unlocker doesn't work on 64-bit OS, LockHunter does though.
Here is how I solved this problem
*I open the project Properties,
*select the build tab,
*Clear the output path,
*and buid(this will create the dll in the root folder)
*come back to the output path and select browse(browse to the bin directory to either debug/release)and voila!
As per Error: Cannot access file bin/Debug/… because it is being used by another process answer by TarmoPikaro, sometimes Visual Studio creates multiple msbuild.exe ghost processes, which persist after build. These ghost processes seem to be causing file locks.
Solution 1 - Kill ghost MSBuild.exe's
Killing msbuild.exe's is a one time solution, it needs to be done per build basis.
You can kill the processes as follows mrtumnus:
taskkill /f /im MSBuild.exe
Solution 2 - Disable parallel builds in Visual Studio
You can disable parallel build once and for all:
Tools > Options > Projects and Solutions > Build and Run > "maximum numbers of parallel project builds" - by default it has value of 8, switch it to 1.
Of course builds are bit slower now, but mileage may vary depending on your use case.
This is related to
Error: Cannot access file bin/Debug/... because it is being used by another process
I've seen the Windows Indexing Service cause this. Disabling it helped. Virus scanners can also be at fault. Mutliple Application.Close() calls can supposedly cause this, too.
Of course, since it always works the first time, I suppose these are unlikely.
Had the same problem. The following things helped
Closing all design files while debugging
using unlocker
Also my application opens a port. While debugging an exception was thrown and program quit. While ending the program I closed the port. That helped too.
But definitely, bug with VS2010.
I encountered the same problem and in my case I had the file in question open in Visual Studio. Closing all files helped.
I faced the same error and I was stuck in it for many days. Finally resolved the issue.
I was working on a project that had many class libraries added in it. I added the reference of these libraries to my main project and mistakenly added reference to same project to itself. So when I removed self reference, it worked.
I had this issue myself. I had the project properties window open and that apparently creates a file lock. Even after I closed the window the file lock remained and I had to restart VS.
P.S. I'm using VS 2019. Just posting this for anyone having the issue I had and coming to this post.
If you get this error on VS Code;
Click on terminal screen and use "Ctrl + C" for stop running.