Related
so I have a project that was housed in another directory that I copyied and moved into another directory in order to dump it into a local git repo that was previously running an earlier version of the code( I know why am I doing this copying stuff well it is a long story and irrelevant). after attmepting to build the project in visual studios 2019 I get the following error during the build.
Severity Code Description Project File Line Suppression State
Error C1090 PDB API call failed, error code '3': C:\Users\chad.lahue\AppData\Local\Programs\Git\TOC\project\TOC\Debug_sim\vc142.pdb TOC C:\Users\chad.lahue\AppData\Local\Programs\Git\TOC\project\TOC\TOC.cpp 1
so after looking up what causes this issue and trying the reboot sugestion to no avail or killing a second msbuild.exe process I have noticed in the task menu that about halfway through the build a second msbuild.exe comes up when building this project and does not on any project that builds successfully
Also the code is the same as well as the project settings as far as I can see from the original directory that it was copied from which still builds just fine.
My question is : 1 is this a code issue / project settings issue or is there some kind of directory or computer glitch?
: 2 has anyone else experienced this type of compiler error and had to resolve it in a more complicated way than what is normally suggested for this error ie. restart computer or kill the second msbuild.exe ? better yet has anyone ever had a project that generates 2 msbuild.exe's during the build process which causes it to fail as it appears to be here?
for others experiencing this issue despite updating their vs like I did the following project settings fixed the issue for me, I have also tried the /FS solution on another project that started experiencing the same issue
For those getting the issue with vc142.pdb try setting "Configuration Properties->C/C++->Output Files->Program Database File Name" to "$(TEMP)vc$(PlatformToolsetVersion).pdb"
It could also work for the other pdb's by setting "Configuration Properties->Linker->Debugger->Generate Program Database File" to "$(TEMP)$(TargetName).pdb".
My best guess is the files are being locked by mspdbsrv.exe due to parallel compilation.
for others experiencing this issue despite updating their vs like I did the following project settings fixed the issue for me, I have also tried the /FS solution on another project that started experiencing the same issue an it seemed to clear it up for good as well.
For those getting the issue with vc142.pdb try setting "Configuration Properties->C/C++->Output Files->Program Database File Name" to "$(TEMP)vc$(PlatformToolsetVersion).pdb"
It could also work for the other pdb's by setting "Configuration Properties->Linker->Debugger->Generate Program Database File" to "$(TEMP)$(TargetName).pdb".
My best guess is the files are being locked by mspdbsrv.exe due to parallel compilation.
I had a similar problem except during my CICD process. I found that removing the pdb files from my repository caused the build process to function correctly since the pdbs would no longer be locked down by the build process.
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, when I build + run my application in short intervals I often get the following error. If I just wait a minute or two and try again it works fine. Unlocker claims no handle is locking the executable file. How can I discover what's locking it? If it's Visual Studio itself, what should I do to make it stop? or alternatively to release the file?
1>------ Build started: Project: MyProj, Configuration: Release Win32 ------
...
1>InitializeBuildStatus:
1> Creating "Release\MyProj.unsuccessfulbuild" because "AlwaysCreate" was specified.
1>ClCompile:
1> All outputs are up-to-date.
1> SomeFile1.cpp
1>ResourceCompile:
1> All outputs are up-to-date.
1>LINK : fatal error LNK1104: cannot open file 'D:\...\MyProj.exe'
1>
1>Build FAILED.
1>
1>Time Elapsed 00:00:00.94
========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========
Had this issue after a reinstall today. Make sure the Application Experience service is started and not set to disabled. If its set to manual, I believe VS will start it.
I'm aware this is quite old but I just had the same problem with Visual Studio 2010 all patched up so others may still run into this.
Adding my project path to "Exluded Items" in my AVG anti-virus settings appears to have fixed the problem for me.
Try disabling any anti-virus/resident shield and see if it fixes the problem. If so, add your project path to excluded directories in your AV config.
You probably had a stray build process that was locking the executable, and it (the stray process) didn't get cleaned up. In that case, shut down visual studio, open up process explorer, and nuke every process you can find that is related to visual studio.
Then open up visual studio again and try rebuilding your project.
the file can be locked because it is being run now. Try killing the process with a task manager.
Like Jonathan said, yes, renaming can help to work around this problem. But ,e.g. I was forced to rename target executable many times, it's some tedious and not good.
The problem lies there that when you run your project and later get an error that you can't build your project - it's so because this executable (your project) is still runnning (you can check it via task manager.)
If you just rename target build, some time later you will get the same error with new name too and if you open a task manager, you will see that you rubbish system with your not finished projects.
Visual studio for making a new build need to remove previous executable and create new instead of old, it can't do it while executable is still runinng. So, if you want to make a new build, process of old executable has to be closed! (it's strange that visual studio doesn't close it by itself and yes, it looks like some buggy behaviour).
It's some tedious to do it manually, so you may just a bat file and just click it when you have such problem:
taskkill /f /im name_of_target_executable.exe
it works for me at least.
Like a guess - I don't close my program properly in C++, so may be it's normal for visual studio to hold it running.
ADDITION:
There is a great chance to be so , because of not finished application. Check whether you called PostQuitMessage in the end, in order to give know Windows that you are done.
You might have not closed the the output. Close the output, clean and rebuild the file. You might be able to run the file now.
I've concluded this is some kind of Visual Studio bug. Perhaps C Johnson is right - perhaps the build process keeps the file locked.
I do have a workaround which works - each time this happens - I change the Target Name of the executable under the Project's properties (right click the project, then Properties\Configuration Properties\General\Target Name).
In this fashion VS creates a new executable and the problem is worked around. Every few times I do this I return to the original name, thus cycling through ~3 names.
If someone will find the reason for this and a solution, please do answer and I may move the answer to yours, as mine is a workaround.
I had the same problem, however using Codeblocks. Because of this problem i quited programming because everytime i just wanted to throw my computer out of the window.
I want to thank user963228 whos answer is really a solution to that. You have to put Application Experience on Manual startup(you can do it by searching services in windows 7 start menu, and then find Application Experience and click properties).
This problem happens when people want to tweak theyr windows 7 machine, and they decide to disable some pointless services, so they google some tweaking guide and most of those guides say that Application Experience is safe to disable.
I think this problem should be linked to windows 7 problem not VS problem and it should be more visible - it took me long time to find this solution.
Thanks again!
Just to add another solution to the list, what I've found is that Visual Studio (2012 in my case) occasionally locks files under different processes.
So, on a crash, devenv.exe might still be running and holding onto the file(s). Alternatively (as I just discovered), vstestrunner or vstestdiscovery might be holding onto the file as well.
Kill all those processes and it might fix up the issue.
I have just run into the same issue with VS2013, creating device drivers in C++ , and none of the above seemed to fix the issue. However, I have just discovered that in my case the issue appears to have been VMWare-related.
I was running a VMWare workstation client with a shared folder defined on the VM on my entire C: drive. When I disabled the shared folders on the VM Settings, VS2013 was able to happily build my .exe files.
My new process is:
1) Disable the shared folder on the vm (VM Settings | Options | Shared Folders - and uncheck the checkbox)
2) Run the build on the host PC
3) RE-enable the shared folder (and proceed from there)
Hopefully this might help someone else.
(BTW, the errors you receive are that the .exe (or other files) are locked or require Administrator permission, but that is a red herring - It seems to me that the VMWare share is causing those files to appear as locked.)
Usually, this means that your program is locked and might not be killed through task manager or process explorer. I met a similar case that my program had an exception during running and triggered the windows error reporting which locked the program. For the case that windows error reporting locks the program, you can go to control panel->System and Security->Action Center->Problem Reporting Settings to set "Never check for solutions". Hope it helps.
For me it was happening, when I was trying to build in debug mode, but it was working fine in release mode. I changed the build configuration in the visual studio from x86 to x64 and it worked fine for me, as I was running on 64 bit system.
I just had this issue in VS22 - I think I closed the debugger right when it was compiling. All I had to do was restart my computer.
The error comes (at least sometimes) from paths that are too long. In my project simply reducing the output file path does the job:
"Properties/Configuration Properties/General/Intermediate Directory"
Seems that I have hit the 250 character path limitation.
Working with Bjarne Stroustrup Programming Principles and Practice Using C++ "FLTK" example i got the same error but after like 1 hour i got an idea, i tracked one of the libs already seen in Project Properties -> Linker -> Input -> Additional Dependencies, in my case i tracked the kernel32.lib to see where was located and saw there were many kernel32.lib's in different folders. So i started copy the FLTK libs in those folders and the last one i tried worked. Visual Studio 2013 Express found the fltkd.lib and the code worked.
In my case the correct route was C:\Program Files (x86)\Windows Kits\8.1\Lib\winv6.3\um\x86
I don't know how to set that route inside Visual Studio.
Not sure if that Windows kits folder was created when i installed Microsoft Windows SDK for Windows 7 and .NET Framework 4 (ISO) http://www.microsoft.com/en-us/download/details.aspx?id=8442
Hope that helps you people.
I just had thesame problem. With me the exe was still running but I could not end it with the Task Manager. Just by restarting VS, it worked for me.
Mine is that if you set MASM listing file option some extra selection, it will give you this error.
Just use
Enable Assembler Generated Code Listing Yes/Sg
Assembled Code Listing $(ProjectName).lst
it is fine.
But any extra you have issue.
I'm unable to debug a WinForms C# application using the released version of Visual Studio 2010 Prof.
I get the following error message after the second debugging run.
Error 9 Unable to copy file "obj\x86\Debug\Arrowgrass Reports.exe" to "bin\Debug\Arrowgrass Reports.exe". The process cannot access the file 'bin\Debug\Arrowgrass Reports.exe' because it is being used by another process.
I've tried a pre-build script to attempt to delete this file, but it's locked by Visual Studio.
There are a few references to this on the net so it is a know problem. Does anyone have a hotfix or effective work-around?
I have found this issue very easy to reproduce, and the fix for me is a variation on Richard Fors' answer. If I have a UserControl open in the designer, run the debugger, and then edit the UserControl, the subsequent rebuild will fail. If I close the UserControl before running the debugger I never get this error, so I just make sure to close the designer window before hitting F5.
As of October 2012, I still have that issue so the VS 2010 SP1 didn't solve the problem. What I did, and worked consistently, was disabling the hosting process in the projects.
To disable the hosting process:
. Open a project in Visual Studio.
. On the Project menu, click Properties.
. Click the Debug tab.
. Clear the Enable the Visual Studio hosting process check box.
Source:
http://msdn.microsoft.com/en-us/library/ms185330(v=vs.100).aspx
You can try to kill the vshost.exe process:
taskkill /F /IM "Arrowgrass Reports.vshosts.exe"
You might also be lucky and simply be able to move the file in question. Moving the file can be done by adding the following lines of code to the pre-build event of your project:
if exist "$(TargetPath).locked" del "$(TargetPath).locked"
if exist "$(TargetPath)" if not exist "$(TargetPath).locked" move "$(TargetPath)" "$(TargetPath).locked"
Disabling windows search did not fix for me. However disabling Antivirus did (our Antivirus is Symantec Endpoint Protection 11)
As such, I was able to fix this for myself by changing the Debug settings in the project to point the working folder to a path on the C: drive, and then excepting that path from the antivirus auto-protect scan settings.
I hope this helps someone.
I posted this answer in a similar question but figured I'd also say it here:
Alright... this might sound pretty crazy.
I've had this problem in VS2010 for the last couple of years. The workaround mentioned here works for me, but a lot of times I forgot to close all my forms/usercontrols first.
I've discovered that merely going to view the open files via:
Computer Management (compmgmt.msc)->Shared Folders->Open Files
will "Free up" whichever file is being locked. Very strange, but it works for me!
In my case, I did Project Properties-->Security Tab-->Uncheck Click-Once security settings (If it is checked). It worked for me. In my project, it was showing this error for a C++ dll being used in my C# project.
The condition described can also be caused by the offending DLL or EXE referencing itself; in which case the Process Explorer test described previously never returns a match (e.g. it's not running). This unexpected situation seems to be caused during some sequence of operations in VS2010 (and likely all previous versions) which insidiously adds the reference behind the scenes. The specific cause of this hasn't been tracked down (or resolved that I know of). To check for, and resolve this error simply make sure the offending DLL or EXE is not listed as a reference to itself.
Got the error ("The process cannot access the file … because it is being used by another process") when I modified the (Visual Studio 2010 C# Express with SP1) solution from two large (10 source files, ~500 lines per file) projects with one referencing the other, to lots (6) of smaller projects with lots of projects referencing other projects.
The references were to the dll- and exe files (the Debug versions of them), NOT to the projects even though the projects were in the same solution.
I then learned that references should be to projects, not files, for F12 to work properly. So I modified the references. That made F12 work (jump to the source file instead of some auto-generated interface description), and at the same time the "cannot access file" error during build disappeared.
I only got the "cannot access file" error when doing Release builds. The references were to the Debug versions of exe/dll's. I suspect that this mixing is what triggers the bug in VS.
I encountered this issue when developing windows services. I found out that it happens when the service is running. Thus, you only need to stop the service (from the services.msc console) and you're good to go !
Hope this helps.
Tidjani.
Check Task Manager for the specified process and End the process explicitly. This solution worked for me.
I cant' write to a comment since not at 50 points but for me I excluded my project folder in ESET Enpoint Security ver 5. Seems like it blocked/hogged some files. My Error did not state which exe or file was in use so it took a long time to finally get to what JoeC said about Antivirus and tried it. Seems to be working now (Visual Studio 2010 SP1)
Closing recently changed User Controls solved the problem in my scenario. Hope this will help somebody out there.
Looks like this issue has (finally!) been fixed in the VS2010 SP1
http://www.microsoft.com/downloads/en/details.aspx?FamilyID=75568aa6-8107-475d-948a-ef22627e57a5&displaylang=en
Please try uninstalling Windows Live SYNC. Does it still happen?
I think I just found the culprit and the solution.
Go to services and stop & disable the "windows search" service.
That solved the problem for me now.
For me the solution was to change the startup project to a dll (problem only occurs in debug mode when having an application as the startup project). If your solution contains several projects (and it will, and it will contain a .dll, else you would not get the problem), switch to that .dll, no .vshost.exe, no problem.
Also, killing .vshost.exe did not work for me, since immediately after starting again, it had locked the .dll.
Also, make sure to have your references clean, especially in more complex projects, and also prefer project references to assembly references, and so on. I suppose bad references (circular and similar) are bound to cause problems, at least so I have read.
A short article by me on this problem (and my solution)
How to "clean up" your references in a solution
Adding the following to the Pre-build event of the shared dll worked for me:
if exist "$(TargetPath).locked*" del "$(TargetPath).locked*"
set exitprebuildfor$(ProjectName)=
for /l %%a in (1,1,10) do (
if defined exitprebuildfor$(ProjectName) goto :ok
if not exist "$(TargetPath).locked%%a" if exist "$(TargetPath)" move "$(TargetPath)" "$(TargetPath).locked%%a" & set exitprebuildfor$(ProjectName)=1)
:ok
set exitprebuildfor$(ProjectName)=
It's based on the solution given here but instead of just renaming the dll to .locked it keeps trying to rename it to .locked1, locked2. Using 10 I usually run into the problem once a day, but ant value can be used.
Simply make a copy of the whole project and run project from the new copy.... it will work fine.
But you will have to end process of the debug somehow in-order to delete the older project.
Stop IIS service and try building it again or if you can afford to restart your pc, give it a try. Worked for me both ways.
Cheers
My problem was that Outlook 2010 (outlook.exe) was using the same port as my ASP.NET MVC project with IIS express.
Solution: close outlook.exe, run your solution and open outlook again (so that it uses another port).
Hopefully this helps somebody, because I received the same error message as described in this topic.
Try deleting .exe file in debug or release folder (whatever you working on)
Windows will prompt that the process X has opened this and you can't delete it
after that go to task manager and in details tab end task X process
Delete obj file.And stop your service and Restart again.Then you may solve the problem
The best solution for me was to move my project files out of My Documents - which is on a server managed by the IT department - and locate them locally on my C drive. Also working: unchecking the "Enable the Visual Studio hosting process" checkbox, as stated by other people.
If you are working on a C# project which is using reference of C DLL, then you can eliminate the error by checking the Allow unsafe code check box. I know I have not used pointers in my C# project but I was using some bitwise operator in C#. May be these C-like features morphed it as 'Unsafe' code.
What worked for me was removing "read only" status on the bin folder. Once I did that, it has worked ever since.
I've had this error when the project is on a remote share (like, if your $env:homepath is helpfully redirected by your IT department to a network share). Make sure your project is resident on a local drive.
My problem started after creating a custom control and drag and drop it to the toolbox palette for use it in design forms. First appeared a warning saying that there was a redundance between the custom control source file (.cs) and the projects executable (.exe). On executing/debugging appeared the error: unable to access the (.exe) because it's being used (and it was true).
A literally removed the whole source code regarding the custom control and last problem never stopped, until I checked out the references and it was referencing itself in order to be "able to" get the former custom control. I removed the reference and done!!
So: just check the references and remove the self-reference to the project.
Delete your Bin folder and run the application.
This worked for me. :)
Simply turn off Visual Studio hosting in debug, run the project and again re on it and run project.
Open a project in Visual Studio.
. On the Project menu, click Properties.
. Click the Debug tab.
. Clear the Enable the Visual Studio hosting process check box
For Windows Project
The Visual Studio hosting process can hold the executable file pointer. To stop the host instance, open the Project properties and then go to Debug tab. Now uncheck the Enable the Visual Studio hosting Process option and then check the checkbox again to debug.
For web project
The IIS can hold the file pointer. Restarting the IIS can solve the issue.
Recently I started to get this message randomly:
Metadata file '...\Release\project.dll' could not be found in Visual Studio
I have a solution with several projects in it. The current build mode is Debug and all projects' configurations are set to Debug. But when I try to run the main project - sometimes it gives me a few errors, all of which are "Metadata file '...\Release\projectX.dll' could not be found" - and, look, it says about RELEASE folder, though current mode is Debug. Why? I tried to search for reference to "Release\projectX.dll" inside all solution files, and I found one in ResolveAssemblyReference.cache file.
I made a good search over the Internet and found a few people with a similar problem, but there was no solution, or at least no working solution.
I tried to delete references to those projects and read them, but in some time I start getting these errors again.
It seems like a bug. Why does it search for referenced projects in Release folders when I always use Debug mode?
PS. For those who met this problem: I couldn't solve it in an easy way. It disappeared only after I reinstalled Windows :(
Everyone is correct...try everything...(in order of a little to a lot of time wasted)
Do you have bad code? Fix that first.
Clean Solution & Restart Visual Studio
Remove / Add References
Check your build order w/ larger projects and verify
Manually rebuild sub-projects
Manually copy dlls between projects into associated bin folders
Go get some coffee, play some pinball and come back tomorrow...you may think of something else in the meanwhile.
I had the exact same problem. Big visual studio solution with 50+ projects.
All references were added as projects.
Project build order was correct (right click on project and select build order).
However when building some of the higher level projects the "root" project they depended on were not built.
The problem was that these projects were not selected to build under the current configuration (don't know how this happened).
To check this select "Configuration Manager" (Build menu) e check if the problematic projects are set to build.
When you say you deleted references to those projects and re-added them, how did you re-add them, exactly? Did you use the "Browse" tab in the "Add Reference" dialog in Visual Studio? Or, did you use the "Projects" tab (which lists neighboring projects in your solution)?
Edit: If you use the "Browse" tab, and manually add the reference to your .dll that is located in the /Release folder, then Visual Studio will always look for the .dll in that location, regardless of what mode you're currently in (Debug or Release).
If you removed the actual .dll file from the Release folder (either manually or by doing "Clean Solution"), then your reference will break because the .dll does not exist.
I'd suggest removing the reference to ProjectX.dll, and add it in again--but this time, use the "Projects" tab in the "Add Reference" dialog. When you add a reference this way, Visual Studio knows where to get the appropriate .dll. If you're in Debug mode, it will get it from the /Debug folder. If in Release mode, the /Release folder. Your build error should go away, and you also will no longer be (improperly) referencing a Release .dll while in Debug mode.
Well, my answer is not just the summary of all the solutions, but it offers more than that.
Section (1):
In general solutions:
I had 4 errors of this kind (‘metadata file could not be found’) along with 1 error saying 'Source File Could Not Be Opened (‘Unspecified error ‘)'.
I tried to get rid of ‘metadata file could not be found’ error. For that, I read many posts, blogs etc and found these solutions may be effective (summarizing them over here):
Restart VS and try building again.
Go to 'Solution Explorer'. Right click on Solution. Go to Properties. Go to 'Configuration Manager'. Check if the checkboxes under 'Build' are checked or not. If any or all of them are unchecked, then check them and try building again.
If the above solution(s) do not work, then follow sequence mentioned in step 2 above, and even if all the checkboxes are checked, uncheck them, check again and try to build again.
Build Order and Project Dependencies:
Go to 'Solution Explorer'. Right click on Solution. Go to 'Project Dependencies...'. You will see 2 tabs: 'Dependencies' and 'Build Order'. This build order is the one in which solution builds. Check the project dependencies and the build order to verify if some project (say 'project1') which is dependent on other (say 'project2') is trying to build before that one (project2). This might be the cause for the error.
Check the path of the missing .dll:
Check the path of the missing .dll. If the path contains space or any other invalid path character, remove it and try building again.
If this is the cause, then adjust the build order.
Section (2):
My particular case:
I tried all the steps above with various permutations and combinations with restarting VS few times. But, it did not help me.
So, I decided to get rid of other error I was coming across ('Source File Could Not Be Opened (‘Unspecified error ‘)').
I came across a blog:
http://www.anujvarma.com/tfs-errorsource-file-could-not-be-opened-unspecified-error/#comment-1539
I tried the steps mentioned in that blog and I got rid of the error 'Source File Could Not Be Opened (‘Unspecified error ‘)' and surprisingly I got rid of other errors (‘metadata file could not be found’) as well.
Section (3):
Moral of the story:
Try all solutions as mentioned in section (1) above (and any other solutions) for getting rid of the error. If nothing works out, as per the blog mentioned in section (2) above, delete the entries of all source files which are no longer present in the source control and the file system from your .csproj file.
I've had this problem before and the only way I've found to solve it is to run Clean Solution and then restart Visual Studio.
For me it's usually the target framework being off (4.5.2 instead of 4.6) If you fix the target framework of the project to match the target framework of the solution and build, a new .dll will be created.
Re-open Visual Studio as Administrator.
Most of the answares say that you need to remove the libraries of your solution, this is true but when you re-add the libraries the error will be shown again. You need to verify if all the libraries referenced have a compatible .net framework with the .net framework of your solution. Then fix all the errors in your code and rebuild the solution.
Did you check the Configuration manager settings? In the project settings dialog top right corner.
Sometimes it happens that between all the release entries a debug entry comes in.
If so, the auto dependency created by the dependency graph of the solution gets all confused.
I've also seen this error in solutions where I have multiple projects (usually netTiers projects where I've updated one or more of the sub-projects to target the 4.0 framework). It can be problematic to remove. Oftentimes it can be resolved, however, by first fixing all other errors in sub-projects (eg, any missing references), individually rebuilding those sub-projects, then removing/adding back any references to those sub-projects in Visual Studio. Personally, I've had little luck resolving this error by cleaning the solution alone.
We recently ran into this issue after upgrading to Office 2010 from Office 2007 - we had to manually change references in our project to version 14 of the Office Interops we use in some projects.
Hope that helps - took us a few days to figure it out.
In my case it was caused by two things (VS.2012):
1) One of the projects was configured for AnyCPU instead of x86
2) A project that was referenced had somehow the "Build" checkbox unchecked.
Do check your Build | Configuration Manager to get an overview of what is being built and for which platform. Also make sure you check it for both Debug & Release as they may have different settings.
In my case, I had some errors in my code. Visual Studio showed the error you had instead of the actual errors, like syntax errors or unknown class names. Try cleaning the solution and building project after project. This way you will discover the actual errors.
Again, this is just what cause the error for me.
I had this problem and took long while to figure it out. Problem came up when I removed projects from solution and replaced those with nuget packages.
Solution seemed to be fine but the .csproj file still contained those projects multiple times as reference.
Seems that VS does not clean that file appropriately. It was still referencing the removed projects under the hood. When manually removed the references from csproj file all works again! wohoo
This problem is due to pdb files or CodeContracts.
To resolve it:
Clean your output folder and rebuild the solution.
Re-Configure the CodeContracts or disable it for temporary build.
We have that problem quite often, but only with references to C++/CLI projects from C# projects. It's obviously a bug deep down in Visual Studio that Microsoft decided not to fix, because it's 'too complex' and they promised an overhaul of the C++ build system which is now targeted for Visual Studio 2010.
That was some time ago, and maybe the fix even went into Visual Studio 2008; I didn't follow up on it any more. However, our typical workaround was
Switch configuration
Restart Visual Studio
Build the solution
I had the same problem myself.
Visual Studio 2013 only told me that it couldn't reference to it, and it couldn't find the metadata. When I opened my solution (which has multiple projects in it) it said that I was using projects lower than the framework version of one of my projects.
So I switched everything to version 4.5, and it worked again.
I seem to recall having a similar problem a few months ago. I solved it temporarily by copying the referenced DLL to the Release folder, thus satisfying Visual Studio's expectations. Later, I discovered the reference to the Release DLL in my actual code. You should try doing a search through the entire project for \release\project.dll.
Also, I have noticed that Visual Studio unit test projects sometimes put a "DeploymentItem" attribute on each of the test methods pointing to your target DLL, and if you switch between Debug and Release, Visual Studio can get confused if the DLL is no longer in the expected location. In my experience, these attributes can be safely deleted if you didn't put them there yourself as part of a "single deployment" scenario.
I had this problem and it was due to an invalid method in the offending library (dll) that did not return a value, e.g.
public bool DoSomething()
{
//I never bothered putting code here....
}
When I commmented this out everything compiled :)
Sometimes VS2010 switches my configuration from Any CPU to Mixed Platforms. When this happens I get this error message.
To resolve it I switch back to Any CPU:
1. Right click on the solution and select properties.
2. Click on Configuration Properties and then the Configuration Manager... button.
3. Under Active solution platform select Any CPU
I find that this usually occurs to me when i still have a method declaration in an interface, which a class implements, but that i had later removed and had forgotten to remove it from the interface as well. I usually just save the entire solution every 30mins n then just revert back to an earlier version if i cant find the error.
I ended up deleting my references (I had added them properly using the projects tab, and they used to build just fine), hand editing my .csproj files and removing bizarre entries that didn't belong -- and setting my outputs for debug and release, x86 and x64 and any cpu to all be "\bin" -- I built it once, then re-added the reference (again, using the projects tab), and everything started working again for me. Didn't have to restart Visual Studio at all.
For me this was caused by the Build target having been rewritten to not output the dll. Removing this to fall back on the default Build target fixed the issue.
For me was to remove/delete entire .vs folder(that is an invisible one) and then:
- Build
- Rebuild
and done.
in my case i was working on a branch off master. so i checked out master branch, ran a build and then checked out my branch. It fixed the issue. If you already are on master, i suggest you check out previous commit and then build it.
It seems to happen when you checkout a solution with multiple projects that have references between them, and you haven't built it before. If you have references directly to the dlls, instead of referencing the project, you'll get this message.
You should always use the Projects tab in the Add Reference dialog to add a reference to a project in the same solution. This way, VS can know the correct order in which to build the solution
same happened to me today as described by Vidar.
I have a Build error in a Helper Library (which is referenced by other projects) and instead of telling me that there's an error in Helper Library, the compiler comes up with list of MetaFile-not-found type errors. After correcting the Build error in Helper Library, the MetaFile errors gone.
Is there any setting in VS to improve this?
I had the same problem. I noticed that my db context (EF4) that was located in the project dll wasn't recognize for some reason. I deleted it and created another one instead. and that solved it for me.
Had the same problem today.
My application, a Windows Forms applications, accidently had a reference to itself. Weird.
Once removed, the error went away.
The reference got added each time I dragged a user control, located in the Windows Forms project itself, to a form.
I had the same problem. Manually removing and adding the dlls did not help. ClassLibraries did not compile for all the projects and were missing in the ...\bin\Debug folder for the project [because I cleaned solution by mistake]. Since the class library did not compile that means there may be some errors somewhere in one of those sub projects.
Solution: Since my dlls were there for the ...\bin\Release folder, I tried to rebuild on Release mode and found an error on one line in one of the sub projects. Solving the error and rebuilding the solution got rid off the build error.