VS2010 doesn't always release dlls before building

Question

I have a periodically occurring problem when building with Visual Studio 2010. Sometimes it refuses to build with an error message like:

Error 102 Unable to copy file "xxxxx\Debug\Services.dll" to "bin\Debug\Services.dll". The process cannot access the file 'bin\Debug\Services.dll' because it is being used by another process.

The only remedy I have found is to restart Visual Studio. Closing the solution is not enough. I have tried to find the culprit with Process Explorer since I suspected that one of my own threads didn't close down as it should. However the process is devenv.exe, i.e. Visual Studio itself. Also I get this symptom only with VS 2010 even when building upgraded VS 2008 projects. I never experienced this problem with the same projects under VS 2008.

I have a lot of custom made WPF user controls and I have a theory that it is the WPF designer that sometimes hold on to the control's dependent dll's when it should be releasing them for a build. The theory is not well established since this is a periodic problem and sometimes it occurs without the designed being open. I also have the same problem for a windows forms project. Sometimes I get through a day without a locked dll. Sometimes it is every other build or so.

I have asked Microsoft about the problem and they told me to make a dump of Visual Studio and debug the dump. I didn't find that to be sound advice.

Have anybody experienced something similar? It is really annoying.

Update 1

Since this appears to be a Visual Studio bug and Microsoft has responded that they do not intend to do anything about it I would like to encourage everybody who works with custom user controls to up-vote this bug at connect.microsoft.com.

The bug is both reported here: https://connect.microsoft.com/VisualStudio/feedback/details/587281 and by me here https://connect.microsoft.com/VisualStudio/feedback/details/568672

Update 2 I have hacked together a simple Visual Studio macro that closes down all .XAML files before building. So far I have not experienced the lockup with this macro. Add the following macro in Visual Studio and assigned to your favorite build short cut. Maybe / maybe not that will fix the problem.

Imports System
Imports EnvDTE
Imports EnvDTE80
Imports EnvDTE90
Imports EnvDTE90a
Imports EnvDTE100
Imports System.Diagnostics

Public Module CloseXamlAndBuildModule
    Sub CloseXamlAndBuild()
        For Each myDocument As EnvDTE.Document In DTE.Documents
            If myDocument.Name.EndsWith(".xaml") Then
                myDocument.Close()
            End If
        Next
        DTE.Solution.SolutionBuild.Build()
    End Sub

End Module

Answer 1

I have the same problem in C#. If you rename the DLL, you don't need to restart Visual Studio. But it's still annoying.

Answer 2

This is a fairly persistent complaint about VS2010 although it is not wide-spread. I haven't seen a good diagnosis for it yet. The feedback item to watch is this one, it seems to be the collector for most duplicates. Getting it resolved quicker probably is going to require opening a case at Microsoft Support.

Answer 3

Try using VSCommands plugin. It has option to 'Apply Fix' that will allow you to close any process which keeps the file locked (most often than not it is vshost process which can be killed).

Answer 4

I actually reported this problem to Microsoft Connect a while ago, but had not checked up on the issue in a while. My original report to Microsoft is here.

Among the comments is a way to reproduce the issue with custom user controls (as I suspected).

Microsoft just replied with a standard "thank you for your feedback, your suggestion does not meet the criteria to be addressed". Thank you Microsoft. I guess I will just have to live with restarting Visual Studio a couple of times every hour.

Answer 5

I have the same problem with a Windows Forms project. I'm also using Team Foundation Server, could that be something? Are you using a source control system ?

Marcel