6

I am getting the warning MSB3061 indicating that the output file (in this example a dll) cannot be deleted

Error message:

------ Rebuild All started: Project: CapInfo, Configuration: Release x86 ------
C:\Program Files\MSBuild\12.0\bin\Microsoft.Common.CurrentVersion.targets(4319,5): warning MSB3061: Unable to delete file "C:\CapInfo\CapInfo\bin\Release\CapInfo.dll". Access to the path 'C:\CapInfo\CapInfo\bin\Release\CapInfo.dll' is denied.
  CapInfo -> C:\CapInfo\CapInfo\bin\Release\CapInfo.dll
========== Rebuild All: 1 succeeded, 0 failed, 0 skipped ==========

Most of the workarounds I have seen on this have suggested that changing the AssemblyVersion and AssemblyFileVersion fix this but this is not the case for me.

I my case this happens all the time but only on certain solutions yet all are being built in the same way by shelling MSBuild (the error also occurs when compiling in the IDE)

I can't simply delete the file in this case either because this is registered for COM interop, so during compile VS unregisters it. If the file is deleted then the unregistration fails with a different warning message)

I have also tried adding the following to the project properties (.vbproj file) with no success:

<GenerateResourceNeverLockTypeAssemblies>true</GenerateResourceNeverLockTypeAssemblies>

I also tried adding 

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

To the pre-build event. This creates the locked file but still generates the warning

The most annoying part is that the compilation and copy actually works (VS does a retry then it works) so my questions are this

  1. Is there any other solution out there that might work for me in this case
  2. Is there a way I can add a pause to the build process before attempting to delete the file?
  3. Can I just disable this compiler warning (it doesn't show in the warning configurations table)

EDIT:

This appears to be something to do with the COM registration because if I untick "Register for COM Interop" I do not get the Warning anymore

EDIT2:

This install is on a HyperV virtual Windows 7 box. I have found that moving the project to a network drive and compiling onto that drive does not throw this warning, so I am investigating if there is some slow disk writing going on.

Matt Wilko
  • 26,994
  • 10
  • 93
  • 143
  • If you have antivirus installed you might configure it to exclude your project and build folders from scanning, in case it's trying to lock the files during the build. – Darth Continent Jan 28 '14 at 14:38
  • @DarthContinent - I tried temporarily disabling AV altogether and this did not have any difference – Matt Wilko Jan 28 '14 at 14:43
  • 1
    hm. Have you tried stopping/restarting the app in component services after unregistering the DLL? – James S Jan 28 '14 at 14:48
  • 1
    @JamesS - the unregistration/reregistration all happens during compilation so there is no pause in proceedings to manually stop-start services – Matt Wilko Jan 28 '14 at 14:50
  • Well this is purely speculation now, but you could try using the MsBuild Extension Pack to shutdown the COM+ app as part of the build. See [link](http://www.msbuildextensionpack.com/help/4.0.8.0/?topic=html/dab48c6f-9775-22d4-988b-81eba0e3a3a6.htm) – James S Jan 28 '14 at 14:58
  • @JamesS - sorry what do you mean by "the COM+ app"? – Matt Wilko Jan 28 '14 at 15:07
  • sorry it's been a while since I've done any COM+ (or COM+ InterOp) - I assumed you had a COM+ application using the DLL after it was registered. If nothing is using it then this is probably irrelevant. Maybe the best thing to do is add a pause (like you suggested - see [link](http://stackoverflow.com/questions/2542672/how-to-pause-in-the-middle-of-the-execution-of-a-msbuild-script) ) and then maybe use the SysInternals Process Explorer to see what locks are on the file. As an aside - is there any good reason for registering the DLL as part of the build anyway? – James S Jan 28 '14 at 15:17
  • @JamesS - I believe it is the Un-registration that is causing the issue. This is required so that the registry is cleaned up before the new version is compiled. – Matt Wilko Jan 30 '14 at 09:52
  • 1
    This is a chronic environmental problem, some kind of component keeps the DLL loaded longer than expected. Almost always an anti-malware problem, Avast is very notorious for loading DLLs to scan them without delete sharing. You can chase it down with SysInternals' Process Monitor. You should see whatever process is finally closing the file handle. Hopefully it is not some kind of DLL that got injected into MSBuild.exe or you still don't know anything. – Hans Passant Jan 30 '14 at 13:28
  • I had a similar problem and restarting VS did the trick. – Pablo Claus Oct 30 '14 at 15:06
  • @Pabloker - Funnily enough I did try that – Matt Wilko Oct 30 '14 at 15:25
  • I had exactly the same issue on Oracle Virtual Box. – Nikolay Dec 08 '14 at 01:22
  • Please see this answer: http://stackoverflow.com/a/4558180/360840 I had the exact same problem, and turning on the Application Experience service fixed it immediately. FYI. – Sabuncu Apr 09 '15 at 21:04
  • 1
    I ran into this problem after upgrading to VS2015 from VS2010. In my case it is related to COM Interop. The only solution I found for my little build batch file was to do a clean on all the projects before building. The clean sometimes gets the error but the build works after the clean. – Kevin Gale May 27 '16 at 13:44

0 Answers0