Geek Answers Handbook

Visual Studio 2010 constructor error: cannot copy from obj \ debug to bin \ debug

I wonder if anyone has a solution to this 2010 bug. I have a project that works fine in Visual Studio 2008, which will not be built in 2010, because Visual Studio keeps the DLL after starting the application ONLY if the designer window is open. I created a really easy project that shows this problem. If you are creating an application then create a dll lib. Put one form in the dll, open the form in the design view, and then run the application. It will work fine, then close the application, go to the form code view in the design view and change the code (I just renamed one variable), then try recompiling, you get the following:

Error 1 Failed to copy the 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 the DLL is in is the devenv.exe file.

I did a ton of searching on this issue and found similar problems with older versions of Dev Studio, where people could just add a preliminary version, a step to move the blocked DLL to another name (.locked) and build. It’s good that it works the first time, but the next time you run, edit, you are blocked both from the current DLL and from the one you moved to .locked, so if I don’t want to add code to randomly create the name for a locked dll, this will not work for me (I don't want my debug directory to grow in size with files that are never deleted.)

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

Does anyone have a better solution to this problem?

+4
source share
2 answers

I'm not sure if this will work for you or not, but this is a 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 problem.

The Visual Studio " VSCommands " application claims to have a fix for this problem. I have not tested it yet, but it also claims to have a reputation tracker built into the IDE stackoverflow that intrigues me :)

Your method "Close designer before debugging" works for me (for now), for which I am very grateful. He began to go on stage, where most of my day was spent in the next workflow ...

  • F5

  • loud sticky

  • ALT F4

  • WIN 3

  • waiting impatiently ...

  • F5
+3
source

I had the same problems for a long time, and then they suddenly disappeared. I realized that the source of the problem was the initialization of the code in the designers of WCF services and WPF controls. After cleaning the designers from any dependencies on other assemblies, everything was in order.

So my suggestion is: clean your constructors.

In WPF, it is possible that the insert:

 if (DesignerProperties.GetIsInDesignMode(this)) return;

or a similar effect will have the same effect.

+1
source

More articles:


All Articles