Visual Studio 2010 Designer Bug: Unable to copy from obj\debug to bin\debug

Question

Wondering if anyone has a solution to this 2010 bug. I have a project that built fine in Visual Studio 2008 that wont build in 2010 because Visual Studio is holding on to the dll after the application is run ONLY if a designer window is open. I created a really light weight project that shows this problem. If you create an application then create a lib dll. Put one form in the dll, open the form in design view and then run the application. It will run fine, then close the app, go to the code view of the form in design view, and change the code ( I just renamed a single variable) then try to recompile you get the following:

Error 1 Unable to copy file "obj\Debug\customlib.dll" to "build\debug\customlib.dll". The process cannot access the file 'build\debug\Customlib.dll' because it is being used by another process.

If you run Process Explorer and search for the dll, the only process holding the dll is devenv.exe!!!

I have done a ton of searching on this problem and have found similar issues with older versions of Dev Studio where people were able to just add a pre-step to move the locked dll to another name (.locked) and build. Well that works the first time, but the next time you run then edit you are locked out of both the current dll and the one you moved to .locked, so unless I am willing to add code to randomly generate a name for the locked dll, this wont work for me (I don't want my debug directory size to grow with files never getting deleted.)

I have only found one workaround and if you are in this same boat this is what I have to do to edit and run. I make sure EVERY design view window is closed BEFORE I ever run my project in the debugger. If you close all the open design view windows devenv.exe will not hold the dll.

Does anyone have a better solution to this problem?

Answer 1

I'm not sure whether this will work for you or not, but this similar question if you have this line in AssemblyInfo.cs:

[assembly: AssemblyVersion("2.0.*")]

changing it to:

[assembly: AssemblyVersion("2.0.0.0")]

will solve this isue.

The Visual Studio add-on "VSCommands" claims to have a fix for this problem. I've not tested it yet, but it also claims to have an in-IDE stackoverflow reputation tracker which intrigues me :)

Your "Close designer before debugging" workaround seems to be working for me (so far), for which I'm very grateful. It was beginning to get to the stage where am large part of my day was spent in the following workflow...

1. F5

2. loud expletive

3. ALT F4

4. WIN 3

5. waits impatiently...

6. F5

Answer 2

I have had the same problems for a long time and then suddenly they disappeared. I realized that the source of the problems was initializing code in the constructors of WCF services and WPF controls. After cleaning the constructors from any dependencies to other assemblies everything has been fine.

So my suggestion is: Clean your constructors.

In WPF it is possible that inserting:

if (DesignerProperties.GetIsInDesignMode(this)) return;

or similar will have the same effect.