81

I have a simple WinForms solution in VS 2010. Whenever I build it, output file (bin\debug\app.exe) ends up locked, and subsequent builds fail with a message like "The process cannot access the file 'bin\Debug\app.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"/

Nevermind
  • 1,521
  • 1
  • 15
  • 16
  • occasionally I have a similar problem; do you use windows 7? In my case, it is not VS locking the file: I can just delete it in explorer, and the build runs fine. I noticed the problem happens more frequently if I have an explorer window open on the output directory. Not using a virus scanner btw. – stijn Jan 04 '10 at 21:25
  • Same problem occurs occasionally on Win7, when using NUnit, which is extremely annoying when you are doing some TDD. – Mathias Jun 22 '10 at 17:43
  • @stijn: Not using a on-access virus scanner? Doooh... – TheBlastOne Jul 11 '11 at 12:08
  • This also occurs to me with VS 2013 when I am debugging unit tests and stop the code before VS completes the test execution. If I wait the extra few seconds for VS to unload the test runner, it doesn't happen. – StingyJack Jan 26 '15 at 12:33
  • Maybe this will help: http://www.sevenforums.com/tutorials/194374-indexer-backoff-enable-disable-windows-7-a.html – Roi Shabtai Nov 15 '15 at 05:29
  • I've encountered this problem, and fixed it by the answer here: [Why would SYSTEM continue locking executable file handles after the app has exited?](http://superuser.com/questions/260375/why-would-system-continue-locking-executable-file-handles-after-the-app-has-exit) but it only works if the problem is caused by system. Hope this helps someone. – J3soon Jul 03 '16 at 15:49

16 Answers16

71

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.

if exist "$(TargetPath).locked" del "$(TargetPath).locked"
if exist "$(TargetPath)" if not exist "$(TargetPath).locked" move "$(TargetPath)" "$(TargetPath).locked"
Double_A
  • 99
  • 1
  • 7
Stormenet
  • 25,926
  • 9
  • 53
  • 65
  • Worked for me also. Been having that issue for sometime now. – ritcoder Feb 02 '12 at 03:14
  • This works for me. I tried the %random% version of this as per Vladimir Datsyuk below, but found that in my case the only file being locked is from the first build after starting up VS, so it only needs to work once. I am on VS 2013, and not using the gui designer either, just a big solution with lots of references & T4 template projects. – Davos Feb 09 '15 at 08:00
  • 5
    I needed to rename the PDB too, as it was locked also: `if exist "$(TargetDir)$(TargetName).pdb.locked" del "$(TargetDir)$(TargetName).pdb.locked" `, `if exist "$(TargetDir)$(TargetName).pdb" if not exist "$(TargetDir)$(TargetName).pdb.locked" move "$(TargetDir)$(TargetName).pdb" "$(TargetDir)$(TargetName).pdb.locked"` – Tobias J Mar 19 '15 at 14:08
  • Works also for me (Visual Studio 2013). Thx – Anonymous Jan 13 '16 at 09:12
  • Keeps working on VS2017. What's surprising is that the problem persists in VS2017! – Carvo Loco Jun 14 '18 at 09:49
24

It 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. 

del "$(TargetPath).locked.*" /q 
if exist "$(TargetPath)"  move "$(TargetPath)" "$(TargetPath).locked.%random%"
exit /B 0

In case of using constant temporary file names you will just postpone locks:

That workaround works exactly once

 if exist "$(TargetPath).locked" del "$(TargetPath).locked"
    if exist "$(TargetPath)" if not exist "$(TargetPath).locked" move "$(TargetPath)" "$(TargetPath).locked"

I have also found a solution with 2 temporary files that works exactly 2 times.

Vladimir Datsyuk
  • 401
  • 4
  • 7
  • 1
    It happens to me, too, but only if I run my app. I suspect it is the OS keeping an eye on the executeable for caching or whatever reasons. Also, it seems to happen only for apps that call System.Reflection.Assembly.GetExecutingAssembly(), at least in my case. – TheBlastOne Jul 11 '11 at 12:07
  • 2
    OK it seems it happens only if the last run called System.Reflection.Assembly.GetExecutingAssembly, or -and that's news- if any design-time component's source code (source code of any design-time component that is active in the component toolbar) that does a call to System.Reflection.Assembly.GetExecutingAssembly during design-time was open in the editor when the last run started. Got it? – TheBlastOne Jul 14 '11 at 12:23
  • 1
    I think that this problem suddently appeared... Now i have wasted 30 minutes of my life trying to build a project setup.. because i get locking problems! I dont even run the application.. – GorillaApe Jul 20 '11 at 03:25
  • 1
    http://stackoverflow.com/questions/3312646/visual-studio-output-file-permissions/4558180#4558180 that worked for me – GorillaApe Nov 17 '11 at 13:31
  • 1
    Additional for the pbd file: `del "$(TargetPath).locked.*" /q if exist "$(TargetPath)" move "$(TargetPath)" "$(TargetPath).locked.%random%" del "$(TargetDir)$(TargetName).pdb.locked.*" /q if exist "$(TargetDir)$(TargetName).pdb" move "$(TargetDir)$(TargetName).pdb" "$(TargetDir)$(TargetName).pdb.locked.%random%" exit /B 0` – Marv Aug 09 '16 at 13:11
  • This problem is in VS 2017 as well and recommended solution doesn't work – gyousefi Jan 08 '21 at 07:35
6

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.

Shani Elharrar
  • 667
  • 4
  • 5
  • 1
    I've been having this exact same issue in all VS11 releases but haven't managed to find a fix yet (unfortunately going without Admin privileges didn't help). Any ideas appreciated! – Dan Nolan Aug 22 '12 at 07:10
4

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.

McAden
  • 13,714
  • 5
  • 37
  • 63
3

What 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.

naivists
  • 32,681
  • 5
  • 61
  • 85
3

Base 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

$(SolutionDir)\BuildProcess\PreBuildEvents.bat  "$(TargetPath)"  "$(TargetFileName)"  "$(TargetDir)"  "$(TargetName)"

Pre build event

Here is the script to copy in the file $(SolutionDir)\BuildProcess\PreBuildEvents.bat (of course you can modify this path):

REM This script is invoked before compiling an assembly, and if the target file exist, it moves it to a temporary location
REM The file-move works even if the existing assembly file is currently locked-by/in-use-in any process.
REM This way we can be sure that the compilation won't end up claiming the assembly cannot be erased!

echo PreBuildEvents 
echo  $(TargetPath) is %1
echo  $(TargetFileName) is %2 
echo  $(TargetDir) is %3   
echo  $(TargetName) is %4

set dir=C:\temp\LockedAssemblies

if not exist %dir% (mkdir %dir%)

REM delete all assemblies moved not really locked by a process
del "%dir%\*" /q

REM assembly file (.exe / .dll) - .pdb file - eventually .xml file (documentation) are concerned
REM use %random% to let coexists several process that hold several versions of locked assemblies
if exist "%1"  move "%1" "%dir%\%2.locked.%random%"
if exist "%3%4.pdb" move "%3%4.pdb" "%dir%\%4.pdb.locked%random%"
if exist "%3%4.xml.locked" del "%dir%\%4.xml.locked%random%"

REM Code with Macros
REM   if exist "$(TargetPath)"  move "$(TargetPath)" "C:\temp\LockedAssemblies\$(TargetFileName).locked.%random%"
REM   if exist "$(TargetDir)$(TargetName).pdb" move "C:\temp\LockedAssemblies\$(TargetName).pdb" "$(TargetDir)$(TargetName).pdb.locked%random%"
REM   if exist "$(TargetDir)$(TargetName).xml.locked" del "C:\temp\LockedAssemblies\$(TargetName).xml.locked%random%"
Community
  • 1
  • 1
Patrick from NDepend team
  • 13,237
  • 6
  • 61
  • 92
3

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.

Enyra
  • 17,542
  • 12
  • 35
  • 44
2

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")]

Robert MacLean
  • 38,975
  • 25
  • 98
  • 152
2

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 data-time info to the file so the renamed versions can't conflict.

Community
  • 1
  • 1
Godeke
  • 16,131
  • 4
  • 62
  • 86
0

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.

willem
  • 25,977
  • 22
  • 75
  • 115
0

If 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.

Onyximo
  • 231
  • 3
  • 6
0

Closing visual studio, reopening, and reloading the most recent solution works around the problem for me. (Visual Studio 2013 Ultimate)

Jay
  • 13,803
  • 4
  • 42
  • 69
0

I 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 

devenv.exe
msbuild.exe

to the process exclusion list.

michael g
  • 603
  • 7
  • 14
  • how did you find out it was windows defender? – Mike May 29 '17 at 21:35
  • my solution worked for a bit but i found out it was actually a major bug in a new VS2017 update release for me. https://developercommunity.visualstudio.com/content/problem/54945/compilaion-fails-because-proces-cannot-access-dll.html – michael g May 31 '17 at 14:17
0

This is the solution I find out

  1. Uncheck the Visual Studio Hosting Process in project settings as shown below

enter image description here

  1. Kill the exe . it will be your applicationname.vshost.exe from taskmanager

enter image description here

  1. Now you can rebuild you application and run.

Note: You can re enable this option again with no problems.

Massimiliano Kraus
  • 3,638
  • 5
  • 27
  • 47
Ramankingdom
  • 1,478
  • 2
  • 12
  • 17
0

I 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.

Konrad Skagerberg
  • 1
  • 1
-8

I have created a new blank solution and added all the old files to it. This somehow solved the problem.

Nevermind
  • 1,521
  • 1
  • 15
  • 16
  • This can't possibly be the answer. Others have provided far clearer reasons for the issue and suitable workarounds that don't require creating a new solution file which is unacceptable when working with version control because the history would be lost. – Bernhard Hofmann Dec 16 '10 at 10:25
  • Yes, this is a bad answer. Others are worse still. Renaming output files is not a solution, it's an unwieldy workaround. If you have better ideas, why not post an answer? – Nevermind Dec 22 '10 at 11:50
  • Creating a new solution did only temporarly solved the problem for me. The best answer seems to be the one from Vladimir Datsyuk. – user492238 Jan 21 '11 at 10:30
  • 1
    Would this solution of yours be optimal if you have like 15 projects in one solutions? – Shittu Joseph Olugbenga Feb 03 '15 at 09:12