Visual Studio locks output file on build

M

16

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

Metallurgy answered 4/1, 2010 at 21:13 Comment(6)

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. – Caldeira 4/1, 2010 at 21:25

Same problem occurs occasionally on Win7, when using NUnit, which is extremely annoying when you are doing some TDD. – Peanut 22/6, 2010 at 17:43

@stijn: Not using a on-access virus scanner? Doooh... – Stepson 11/7, 2011 at 12:8

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. – Killerdiller 26/1, 2015 at 12:33

Maybe this will help: sevenforums.com/tutorials/… – Frias 15/11, 2015 at 5: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? but it only works if the problem is caused by system. Hope this helps someone. – Gizzard 3/7, 2016 at 15:49

M

-8

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

Metallurgy answered 5/1, 2010 at 20:18 Comment(4)

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. – Thain 16/12, 2010 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? – Metallurgy 22/12, 2010 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. – Ambiguity 21/1, 2011 at 10:30

Would this solution of yours be optimal if you have like 15 projects in one solutions? – Auroreaurous 3/2, 2015 at 9:12

D

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"

Doublecheck answered 29/4, 2010 at 15:10 Comment(5)

Worked for me also. Been having that issue for sometime now. – Aweather 2/2, 2012 at 3: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. – Frerichs 9/2, 2015 at 8:0

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"

– Thorma 19/3, 2015 at 14:8

Works also for me (Visual Studio 2013). Thx – Madonnamadora 13/1, 2016 at 9:12

Keeps working on VS2017. What's surprising is that the problem persists in VS2017! – Disinter 14/6, 2018 at 9:49

B

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.

Banwell answered 14/10, 2010 at 15:14 Comment(6)

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. – Stepson 11/7, 2011 at 12:7

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? – Stepson 14/7, 2011 at 12:23

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.. – Tintometer 20/7, 2011 at 3:25

#3313146 that worked for me – Tintometer 17/11, 2011 at 13:31

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

– Jinks 9/8, 2016 at 13:11

This problem is in VS 2017 as well and recommended solution doesn't work – Tattoo 8/1, 2021 at 7:35

S

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.

Skinnydip answered 24/5, 2012 at 18:26 Comment(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! – Lining 22/8, 2012 at 7:10

S

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.

Strutting answered 4/1, 2010 at 21:23 Comment(0)

E

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.

Epact answered 4/1, 2010 at 21:13 Comment(0)

S

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.

Strickland answered 17/2, 2011 at 10:9 Comment(0)

M

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

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

Meissen answered 4/3, 2016 at 15:52 Comment(0)

R

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

Remains answered 9/9, 2010 at 9:51 Comment(0)

N

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.

Natelson answered 14/10, 2010 at 16:6 Comment(0)

P

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.

Particularize answered 9/4, 2013 at 9:4 Comment(0)

J

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.

Jordanjordana answered 15/7, 2016 at 12:51 Comment(0)

S

0

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

Sigismundo answered 6/10, 2016 at 18:30 Comment(1)

Yeah, I have to do that everytime. that is no solution – Biennial 9/3, 2018 at 11:53

E

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.

Edgar answered 16/5, 2017 at 23:35 Comment(2)

how did you find out it was windows defender? – Resor 29/5, 2017 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. developercommunity.visualstudio.com/content/problem/54945/… – Edgar 31/5, 2017 at 14:17

P

0

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.

Popper answered 17/8, 2017 at 6:21 Comment(0)

B

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.

Bugg answered 5/10, 2017 at 22:0 Comment(0)

M

-8