Visual Studio 2008 .dll files cannot be overwritten, access denied

Question

This one is weird. Visual Studio 2008 seems to not be releasing its handle to the .DLLs getting created for my project, so the second time (and subsequent times) I build, when Studio attempts to overwrite the changed .dlls, it gets an access denied error. I also cannot copy/delete the .dll in question (Tasks.dll) while Visual Studio is open after I've built once. Process Explorer tells me that the file is in use by devenv.exe, so I know Visual Studio isn't letting go of it after the build finishes.

Has anyone seen this before, and if so, what can I do about it? Obviously, opening and closing visual studio between every build is not an acceptable solution, and the problem has persisted across system restarts.

Some more background: I am using the error-causing project's DLL (Tasks.dll) in a UsingTask MSBuild directive in another project, let's call it Test. Project build order is set so that Tasks is built before Test, and then Test's AfterBuild task calls a task from /bin/debug/Tasks.dll.

Are you referencing the other projects as projects, or directly referencing their DLLs from their \bin? — Nick Craver
Did you add your bin directory to source control and make them locked? — Keith Adler
The project isn't under source control, so no problem there at least...edited to address the other question — Joel
Are you debugging between builds, and if so do you have a WCF service that causes the background WcfSvcHost.exe to run and hold a handle to the DLL? — Simon Chadwick

Marcin Wieczorek Marcin Wieczorek · Accepted Answer · 2011-11-16T00:10:33

Sure. We had the same problem. I cannot say when exactly the problem occurs and what conditions are to reproduce it, but in our situation it happened in the project in which we had multiple modules and each module referenced multiple other modules, and referenced modules had also references to other modules etc.

It was really annoying, and we lost many hours trying to find out what is the problem, and how it can be solved, but unsuccessfully.

We couldn't refactor project to simplify references (too expensive), we couldn't also spend more time to investigate problem so we found workaround - not perfect, but it helped us, and we use it for years in that project. It is a little bit complicated, but I will try to describe it:

First of all - example project structure
- MyProject (dir)
   - Bin (dir)
     * Proj1.exe
     * Proj2.dll
     * Proj3.dll
   - Src (dir)
      - Proj1 (dir)
      - Proj2 (dir)
          - bin (dir)
      - Proj3 (dir)
          - bin (dir)
Proj1 (which, let's assume is console/windows application - *.exe) has output dir set to MyProject/Bin
Proj2 (.dll) has build output set by default to MyProject/Src/Proj2/bin/... in the postbuild event we copy result to "MyProject/Bin"

copy "$(TargetDir)\$(TargetName).dll" "$(SolutionDir)Bin"
copy "$(TargetDir)\$(TargetName).pdb" "$(SolutionDir)Bin"
Proj3 (.dll) has build output set by default to MyProject/Src/Proj3/bin/... postbuild is the same like for Proj2
And now references. Let's say Proj1 needs reference to Proj2 and Proj2 needs reference to Proj3.
- for the first time build only Proj3, so that in the result of postbuild event commands it will be copied to MyProject/Bin
- now to Proj2 add reference to assembly MyProject/Bin/Proj3.dll (browse to assembly file, do not reference project). In the project dependencies manually set that this project requires to build Proj3 first. Afterwards build "Proj2" so that it will be copied to MyProject/Bin (postbuild event commands)
- and finally to Proj1 add reference to assembly MyProject/Bin/Proj2.dll (again browse to assembly). In the project dependencies manually set that this project requires Proj2 to build firs. And from now you can build whole solution.

Main problems with above approach:

complicated to configure and maintain, especially when project is growing and new projects are added often.
when you will checkout project to fresh directory and you are using tools like ReSharper which analyzes code, it will report lots of errors until first build.
to reduce compilation time you need to manually set for each reference that it should not be copied locally.
this is still sometimes happen that some files are in use, but in our environment it can happen sometimes once per week, sometimes once per month.

Visual Studio 2008 .dll files cannot be overwritten, access denied

2 Answers