Since File Is Locked
VSphere/Veeam: “Unable to access file since it is locked”. The problem is that the virtual machine was crashing every time that I’ve tried to consolidate and wasn’t able to finish without the error: Unable to access file since it is locked. I asked Google and he told me a lot of thing, but not THE solution for my problem.
I have a simple WinForms solution in VS 2010. Whenever I build it, output file (bindebugapp.exe) ends up locked, and subsequent builds fail with a message like 'The process cannot access the file 'binDebugapp.exe' because it is being used by another process.'
The only way to build the project is to restart VS after every build, which is very awkward.
I have found this old blog post http://blogs.geekdojo.net/brian/archive/2006/02/17/VS2005FileLocking.aspx - it seems that the problem is really old. Does anyone know what is happening here, or at least some workaround?
Update
I don't actually run the file. Locking happens after build, not after debug (i.e. start VS - build - build - fail!)And I tried turning antivirus off. It doesn't help.
Update 2
Process Explorer shows devenv.exe having loaded the file (in DLLs, not in Handles). It seems like some glitch during build prevented the unloading, but the (first) build completes without any messages other then '1 succeeded, o failed'/
16 Answers
Had the same issue, but found a solution (thanks to Keyvan Nayyeri):
But how to solve this? There are various ways based on your project type but one simple solution that I recommend to Visual Studio add-in developers is to add a simple code to their project's build events.
You can add following lines of code to the pre-build event command line of your project.
StormenetStormenetIt is not a virus issue. It is visual studio 2010 bug. It seems the issue is related to using visual studio gui designer.
The workaround here is to move locked output file into another temporary one in pre-build event. It make sense to generate temporary file name randomly.
In case of using constant temporary file names you will just postpone locks:
That workaround works exactly once
I have also found a solution with 2 temporary files that works exactly 2 times.
The problem occurred to me too.
My scenario was this : Running windows 7 (But might also happened in Windows XP) and while working on a project with WPF User Control I could build all of the times, Until opening the XAML file of the User Control - From there, I've got one build, and then the files are locked.
Also, I've noticed that I was running Visual Studio (Devenv.exe) as Administrator, I've started to run Visual Studio without Administrator privileges and the problem was gone!.
Let me know if it helped you too. Good luck.
I've seen this on either a greedy virus scanning software, or if app.exe isn't shutting down properly. Make sure the process isn't still running.
McAdenMcAdenWhat about virus scanners on your machine? Can you see any processes that are holding handles to your file (use Process Explorer to find out)?
Maybe there is 'app.exe' visible in your process list, i.e the last version you debugged is still running? When you develop applications which have multiple threads, this may happen if you don't join
all of them.
I had the same problem and I found out, that VS only locks the exe when I opened a Form or UserControl in VS before building.The solution was quite easy, I just had to close any Form/UserControl before I build the solution and it worked.
EnyraEnyraBase on the great Stormenet answer, I put up a small script that should work in all cases.
Here is the code to put in the pre build event text box
Here is the script to copy in the file $(SolutionDir)BuildProcessPreBuildEvents.bat
(of course you can modify this path):
There is also a known issue 533411 where the usage of automatically updating build numbers can cause the locking issue. Workaround from bug report
Temporary workaround would be disable assembly version update after the rebuild. In AssemblyInfo.cs file, remove the wild card from the AssemblyVersion attribute, for example:
replace this:
[assembly: AssemblyVersion('1.4.*')]
[assembly: AssemblyFileVersion('1.4')]
with this:
[assembly: AssemblyVersion('1.4.0.0')]
[assembly: AssemblyFileVersion('1.4.0.0')]
I had this problem and resolved it with some custom code. See here: Visual Studio 2010 build file lock issues
Compile the utility in the accepted answer and reference it during the build step as described to workaround the problem. I still turn off VS 2010 at lunch to clean up the morning's work.
The reason for the custom code was that the often recommended solution only worked once and then the renamed files were also locked, preventing the rename. Here we just append the>33 gold badges49 silver badges81 bronze badges
The only thing that worked for me was to quit Visual Studio 2012, delete the BIN and OBJ folders for the project having problems, and to open Visual Studio again.
Problem solved... Until next time.
willemwillemIf your $(TargetPath) points to a DLL that uses COM ensure you have a default constructor. Not sure why the default constructor is not inferred there. Adding the default constructor worked for me in this scenario.
Closing visual studio, reopening, and reloading the most recent solution works around the problem for me. (Visual Studio 2013 Ultimate)
JayJayI ran into the same thing developing xamarin apps in VS2017.
It happened to be Windows Defender locking the exe/dll with devenv.exe.
You can go to Win Defender and add
to the process exclusion list.
This is the solution I find out
- Uncheck the Visual Studio Hosting Process in project settings as shown below
- Kill the exe . it will be your applicationname.vshost.exe from taskmanager
- Now you can rebuild you application and run.
Note: You can re enable this option again with no problems.
Massimiliano KrausI managed to fix this problem by disabling McAfee LiveSafe real time scanning. My .exe file would lock up like the OP describes and I would have no way to remove the file, which meant I could not build the solution. After disabling the McAfee feature the problem was gone.
Then I of course went on to fully uninstall McAfee, which was only installed because my PC is new and it came with the program already installed.
I have created a new blank solution and added all the old files to it. This somehow solved the problem.
NevermindNevermindNot the answer you're looking for? Browse other questions tagged visual-studio or ask your own question.
This question already has an answer here:
- Microsoft Office document is “locked for editing by 'another user'” 11 answers
View Locked Files
I'm opening an Excel file and I'm getting the File in use pop-up that says it's locked for editing by me. However, I've not got it open on this computer (I think I had it open and my machine blue-screened). How do I go about fixing this?
Should specify, this is a file on a file share.
edit I'm not talking about if this is being used by another user on another machine, this is only accessible by me on this file share.
marked as duplicate by gronostaj, slhckAug 20 '14 at 10:39
This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.
1 Answer
Microsoft Office tracks those locks using files that are created in the same directory as the original file. The document Somedoc.docx
gets a temporary lock file (Microsoft calls it an 'owner file'): ~$Somedoc.docx
. The same goes for Powerpoint and Excel. The owner of that file is the owner reported in the dialog.
The easiest way out is to delete that file. It is a hidden file, so you should set your Windows Explorer to view 'protected operating system files':
- Open Folder Options by clicking the Start button, clicking Control Panel, click Appearance and Personalization, and then click Folder Options.
- Click the View tab.
- Under Advanced settings, click Show hidden files, folders, and drives,
- Un-Check
Hide protected operating system files (Recommended)
, and then click OK.
You should see that file in the same directory the original file is in. Delete it and open the document again.
This situation is explained more elaborately here .
Máté Juhász