11

I have a rather large .NET 2.0 solution (151 projects) in Visual Studio 2008. Often times when I do a build (even for just one project) in VS I get an error saying that it can't copy one of my DLL assemblies to the output directory because it is in use. I don't have any other processes running in the background or existing debug sessions going that would be using this assembly. If I open up Process Explorer and do a search for this assembly name Visual Studio (devenv.exe) comes up as the only result. Looking at the results Visual Studio has my assembly loaded as a DLL for some reason. Closing the solution and reopening it doesn't solve the problem. I have to completely exit out of VS altogether to get around this issue which is quite disruptive. Does anyone have any idea what is going on? I'm running on Window 7, I don't think I saw this issue on Windows XP.

I am running Visual Studio 2008 Version 9.0.30729.1 SP. I'm also running ReSharper 6 if that matters.

Dennis
  • 532
  • 7
  • 21
  • What does your application do? Is it multithreaded, and maybe you're not properly killing a thread when you stop the program execution? – Steven Evers Aug 04 '11 at 14:43
  • @Snorfus - What his program does exactly is not important. Its also not important if its multithread, the problem surfaces when he is trying to build the solution, so the program itself is not even running at that point. Visual Studio does keep everything handy in order to reference say a library solution within your project. It can get confused and not release it before you hit rebuild and/or build. – Security Hound Aug 04 '11 at 14:45
  • Possible duplicate: http://stackoverflow.com/questions/2002273/visual-studio-locks-output-file-on-build – Simon Fischer Aug 04 '11 at 14:54
  • @Simon Fischer - While similar that question is different. – Security Hound Aug 04 '11 at 15:14
  • 151 Projects. Wow. Are they all dependent on each other, or do you just find it more convenient to have them all open just in case you want to work on something else? Personally I just have a bunch of different solutions with the minimal number of projects to compile whatever it is I'm actually working on. I find it saves a lot of time. – Kibbee Aug 04 '11 at 15:16
  • Is the problem DLL relatively large (say, over 800k)? Does that project contain "controls" or other components that are imported into the VS toolbox? – lnmx Aug 04 '11 at 15:24
  • @Ramhound: I asked, because I have specifically experienced this problem under the circumstances that I described. – Steven Evers Aug 04 '11 at 15:46
  • @Kibbee - I tried splitting the solution up a couple months ago but it was too complicated because there were many interdependencies across several projects (e.g., A just uses B and C, but B and C each use a bunch of different projects). – Dennis Aug 04 '11 at 18:24
  • @Inmex - The DLL in question (which is always the same one) is 150KB (debug build). So it's not very big. – Dennis Aug 04 '11 at 18:24
  • Also, there are no controls or anything fancy in this project. It's actually relatively simple. I have a feeling there is a bug in VS that is triggered due to the complexity of the solution... – Dennis Aug 04 '11 at 18:55
  • @Dennis - It happens to me on a 2 project solution. So the complexity of your solution has very little to do with it. As explained its unlikely a bug per say. – Security Hound Aug 05 '11 at 12:12
  • This happens to me all the time. My solution is just a handful of projects that all tie into the same app, clean fails because the dll is "in use" by Visual Studio, closing/reopening solution and/or visual studio doesn't release it, the only thing that works for me is to close visual studio, then delete those dlls, open vs and resume, it happens enough that I set up a powershell script to do a manual clean. (windows 7, vs2012 ult) – kcar Jan 30 '14 at 21:13

7 Answers7

3

Does anyone have any idea what is going on? I'm running on Window 7, I don't think I saw this issue on Windows XP.

I run into this problem all the time on Windows XP and its not even localized to Visual Studio 2008. What always works for me is I simply clean all solutions, this gets rid of any file that might be in my system's memory, because of Visual Studio.

Visual Studio keeps any your references in memory, so when one of those references is updated, Visual Studio has to release it from memory. If it really happens more then "once in awhile" then you might look at trying to reduce the number of solutions in your project.

Security Hound
  • 2,577
  • 3
  • 25
  • 42
  • I'll try to the clean solution next time this occurs. I really don't like doing a clean because it wipes out all of my temporary and config files that the process creates/uses. Since I have so many projects that have this situation it might actually be less painful to restart VS. – Dennis Aug 04 '11 at 18:28
  • If cleaning the solution doesn't work, the next thing to try is (1) close the solution, (2) re-open the solution. Closing the solution should force VS to release all DLLS it loaded for that solution. – Jesse Chisholm Jun 25 '12 at 21:10
1

Use the following command and place it in "Pre Build Events" of visual studio:

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

Hope this would help you.

sth
  • 222,467
  • 53
  • 283
  • 367
Bhaskar Singh
  • 410
  • 6
  • 15
1

Try to disable the hosting process:

Open an executable project in Visual Studio. Projects that do not produce executables (for example, class library or service projects) do not have this option.

  1. On the Project menu, click Properties.

  2. Click the Debug tab.

  3. Clear the Enable the Visual Studio hosting process check box.

arielhad
  • 1,753
  • 15
  • 12
1

Kill process VBCSCompiler.exe and rebuild.

TKA
  • 124
  • 1
  • 11
0

I would guess that the dll is being used by the (ProjectName).vshost.exe process. You might try killing that process and see if that works. Probably not the best thing to do, but it might be easier than restarting VS.

Paul
  • 948
  • 8
  • 17
  • Nope, the vshost process isn't involved. According to Process Explorer the only process that is using it is devenv.exe (Visual Studio itself). And it has it open as a DLL (not a file handle that could be manually closed from Process Explorer). – Dennis Aug 04 '11 at 18:25
0

I would try the "Clean Solution" option before you build. This can clean up any extraneous temp files that could be hanging around from a program crash.

Lost in Alabama
  • 1,653
  • 10
  • 16
0

I have no idea about why this works, but I had the same problem and when I changed the Starting Project to the project I wanted to build everything worked again.

When I change the Startup project again to the right one I cannot build the other project anymore due to the file being in use, so looks like a bug at the Visual Studio IDE.

Ignacio Soler Garcia
  • 21,122
  • 31
  • 128
  • 207