Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

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

like image 207
Nevermind Avatar asked Jan 04 '10 21:01

Nevermind


People also ask

How do you unlock a file in Visual Studio?

Unlock a folder or file from Source Control Explorer While working in the server workspace, navigate to the View menu and choose Other Windows, then choose Source Control Explorer. In Source Control Explorer, open the shortcut menu for the folder or file from which you want to remove a lock, and then choose Unlock.

How do I lock Visual Studio?

In the Properties window of Visual Studio, select the Locked property and then select true. (Double-clicking the name toggles the property setting.) Alternatively, right-click the control and choose Lock Controls. Locking controls prevents them from being dragged to a new size or location on the design surface.


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

if exist "$(TargetPath).locked" del "$(TargetPath).locked" if exist "$(TargetPath)" if not exist "$(TargetPath).locked" move "$(TargetPath)" "$(TargetPath).locked" 
like image 145
Stormenet Avatar answered Oct 10 '22 07:10

Stormenet


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.

like image 43
Vladimir Datsyuk Avatar answered Oct 10 '22 07:10

Vladimir Datsyuk