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
\"
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.
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.
I have created a new blank solution and added all the old files to it. This somehow solved the problem.
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.
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%"
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.