4

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?

Whymarrh
  • 13,139
  • 14
  • 57
  • 108
Jeff Lundstrom
  • 1,043
  • 1
  • 8
  • 22
  • That's annoying and has been happening in various VS for as long as I remember. Try creating a minimal reproduction project and submitting it to Microsoft Connect with as much info as possible. Maybe you found one they can fix. – µBio Aug 18 '10 at 19:05
  • Excellent suggestion, I just added a bug, lets see what comes of it. – Jeff Lundstrom Aug 18 '10 at 19:32
  • 2
    Here a link to the issue in MS Connect (https://connect.microsoft.com/VisualStudio/feedback/details/587281/vsual-studio-2010-designer-bug-unable-to-copy-from-obj-debug-to-bin-debug) If you have the same problem, click the "I can repro" button. I think the more people who do, the better chance this will get fixed. – Jeff Lundstrom Aug 24 '10 at 19:02

2 Answers2

3

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
Community
  • 1
  • 1
Colin Pickard
  • 45,724
  • 13
  • 98
  • 148
  • I have to have generated version numbers so the workaround does not fix my problem. I was with you on the workflow and I was doing the exact same thing. Thanks for the answer. – Jeff Lundstrom Dec 01 '10 at 19:29
1

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.

Holstebroe
  • 4,993
  • 4
  • 29
  • 45
  • This issue we are having is in Forms and not WPF, although it is happening in our WPF projects as well. I will give that a try. Thanks. – Jeff Lundstrom Dec 15 '10 at 13:44