Visual Studio locks output file on build

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"/

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"

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.

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.

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.

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.

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

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%"

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: https://stackoverflow.com/questions/3095573/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.

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.

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.

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

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.

This is the solution I find out

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

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

3. Now you can rebuild you application and run.

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

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.

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