"MSB3021: Unable to copy file" bug still not fixed in final version

Posted by Kratz on 2/10/2012 at 9:30 AM

Also same as

http://connect.microsoft.com/VisualStudio/feedback/details/90699/receiving-error-the-process-cannot-access-the-file-because-it-is-being-used-by-another-process

which is also closed.

Posted by Kratz on 2/10/2012 at 9:27 AM

Same as http://connect.microsoft.com/VisualStudio/feedback/details/571961/bug-on-build-solution-unable-to-copy-file-because-it-is-being-used-by-another-process#tabs
which is also incorrectly marked as fixed.

Posted by Kratz on 2/10/2012 at 9:21 AM

I can second, VS 2010 bug still exists.

Please re-open this. THIS IS NOT FIXED.

Unable to copy file "x" to "x". The process cannot access the file 'x' because it is being used by another process.

Posted by david develop on 11/23/2011 at 7:41 AM

Visual Studio 2010 SP1, still the same BUG.

Posted by Robert Heinig II on 9/30/2011 at 2:43 AM

Five Years nine Months later: STILL biting us. "Closed as solved"? Sorry, no it isn't.

Posted by Waxime on 7/29/2011 at 10:15 AM

Same problem in visual studio 2010 SP1
one instance
IIS is close
my application didn't appair in my proces list

Posted by rwgreene-i on 11/1/2010 at 2:21 PM

ok, the problem came back and my solution (below) does not work. This project, a WinForm prohject with 15 user controls and 8 forms, will now lock the EXE file on two machines. This work fine until about a week ago, then something changed and now Visual Studio locks the EXE when it Builds the first time, then prevents itself from updating the EXE the next time I press Build button.

-rwg

Posted by rwgreene-i on 10/27/2010 at 10:30 AM

Problem is NOT fixed in VS 2010

I just wanted to say that this problem started with me today. (VS 2010, C#) I have been working on this program for a month without this problem, now today it started. I start VS, change code, compile and test and quit program. Make another change, compile and BOOM Unable to copy file "obj\x86\Debug\progname.exe" to "bin\Debug\progname.exe" because if is being used by another process.

ProcExp shows only Visual Studio (actually devenv.exe) using this file. There is only one instance of VS running. There are two listing on my debug\progname.exe, one is a Type DLL, the other is a Type handle.

Using devenv /ResetSettings did not resolve anything, but wasted 10 minutes putting everything back to my desired view.

Using the PREBUILD events rename trick mentioned above solves the problem for a couple of changes, but on the next change the "exe.locked" file is locked and cannot be deleted. Then the rename fails.

The debug\progname.exe file name remains locked even after closing the project.

There are no add-ins to remove.

Closing VS, manually delete the files in the debug folder, opening VS and my solution, then Build->Clean Solution seems to work for me, at least its working now after I did all of that stuff.

Hope this helps
-rwg

Posted by overbaud on 2/27/2008 at 9:20 PM

Regarding error MSB3021 "Unable to copy file XXXX.dll. The process cannot access the file XXX.dll because it is being used by another process."

I encountered this productivity killing issue and after doing all of the usual:

> Removing references and recreating
> Turning of indexing
> Pre / post compile scripts
><GenerateResourceNeverLockTypeAssemblies>true</GenerateResourceNeverLockTypeAssemblies>

Found the solution to be:

Changing the assembly name from Security to PSS.Security in the project properties.

It clicked that the error had occured when I changed my assemblies to not have the name space in front of them the night before eg. WAS [Company].PSS.Security.dll CHANGED TO JUST Security.dll.

I changed it back and the x.x.vshost.exe MSB3021 lock was not appearing any more on run. As a further test I changed it back to just Security.dll and it failed again... changed it to Something.Security.dll and it worked again.

Hope this helps find a permanent fix (which really is needed) and a workaround in the meantime.

Scott Pinkerton

Posted by Microsoft on 1/26/2007 at 10:39 AM

I'm adding code to fix these problems, but I can't verify for sure that they're fixed without good reproes in-house. If anyone posting on this issue can reduce their projects down to the minimum that reproduces the problem (without the GenerateResourceNeverLockTypeAssemblies workaround), please zip it up and send it to MSBUILD@MICROSOFT.COM. I'll use it to verify my fix, and to create an automated test to prevent it ever regressing. This is your and our best assurance that we don't ship this same bug in MSBuild Orcas.
Thank you in advance,
Dan (MSBuild team)

Posted by Microsoft on 8/23/2006 at 1:22 PM

To anyone else that encounters this bug:
Please verify that you have something like this in one of your resx's:
<data name="..." mimetype="application/x-microsoft.net.object.binary.base64">
If you DON'T have this in any of your resx's, please email msbuild@microsoft.com so we can figure out what is causing it.
This mimetype will be serializing an instance of a type defined in the assembly that your copying is failing on. (If this ISN'T the case, please also email us.)
In the meantime you can add the <GenerateResourceNeverLockTypeAssemblies>true</GenerateResourceNeverLockTypeAssemblies> property to the projects that have this mimetype one of their resx's and you should be unblocked.
Dan (msbuild@microsoft.com)

Posted by orbit3032263 on 3/1/2006 at 1:07 AM

I have checked my 162 resx files

Besides the appearance of mimetype="application/x-microsoft.net.object.binary.base64" in the remark part of the sample of each I could find only one productive entry:
<data name="imlNKVTree.ImageStream" mimetype="application/x-microsoft.net.object.binary.base64">
It's the representation of some images in an ImageList for a TreeView

The rest are some dozens of mimetype="application/x-microsoft.net.object.bytearray.base64" for icons etc.

Posted by Microsoft on 2/28/2006 at 11:26 AM

Hi Stephan,
You asked what the blobs look like that cause this problem. The answer is something like this in your .resx file:

<data name="something.somethingelse" mimetype="application/x-microsoft.net.object.binary.base64">
<value>
AAEAAAD/////AQAAAAAAAAAMAgAAAGpXaW5kaGF........... lots more base 64 encoded goo ....
</value>
</data>

This is legitimate data. The workaround of adding <GenerateResourceNeverLockTypeAssemblies>true</GenerateResourceNeverLockTypeAssemblies> will slow down your build a bit, but should avoid the failure.

If we issue a patch for this bug in future, we'll share that information here.

Dan (msbuild@microsoft.com)

"This posting provided "AS-IS", with no warranties."

Posted by orbit3032263 on 2/27/2006 at 12:28 PM

Hey this really did the trick

I added <GenerateResourceNeverLockTypeAssemblies>true</GenerateResourceNeverLockTypeAssemblies> to the nkv.WinUI.vbproj and did not encounter this nasty behavior anymore.

nkv.WinUI.vbproj is the project containing all the UI stuff that references objects in nkv.BusinessRules.dll

The solution uses LOTS of resx files but I am not aware of any 'deserialized blobs of data'

Could you further explain?

Thanks
Stephan

Posted by Microsoft on 2/20/2006 at 6:30 PM

Dear "Orbit" and Theo,

We think we have a work-around for this bug. However, we need to ask you a couple of questions:
1) Do your solutions have .resx files that contain deserialized blobs of data?
2) If so, are these blobs type references to types that are contained in the assemblies that get locked?

For example, in Orbit's case, the "bin\nkv.BusinessRules.dll" assembly is getting locked. So is there a project in your solution that contains .resx files with type references to types in the "nkv.BusinessRules.dll" assembly?

If this happens to be the case, then the workaround is to add a certain property to the project that contains the .resx files. If you open up the project in an XML editor, you can add this property to the first <PropertyGroup> in the project: <GenerateResourceNeverLockTypeAssemblies>true</GenerateResourceNeverLockTypeAssemblies>

Please let us know if that fixes your locking problems. Many thanks!

--MSBuild Team

Posted by Microsoft on 2/7/2006 at 11:26 AM

The Microsoft Sub-status is now "Working on solution"

Posted by Microsoft on 1/25/2006 at 12:54 PM

Thank you for submitting this issue. I'm passing it to the feature team to take a look.

-Shamez

Posted by orbit3032263 on 2/23/2006 at 5:25 AM

VS only locks one version of the file, and you CAN rename/move it.
You can use the following commands in the pre-build event of the
problem-project to workaround the problem:

Source:
http://groups.google.ch/group/microsoft.public.dotnet.languages.csharp/browse_thread/thread/d63d6c5c6fd3f83c/9ad9d6ed734fc75b?lnk=st&q=Unable+to+copy+file+because+it+is+being+used+by+another+process.+vs+2005&rnum=2&hl=de#9ad9d6ed734fc75b

http://groups.google.ch/group/microsoft.public.dotnet.languages.csharp/browse_thread/thread/56170b131cf3bd7/62a5440b17e07260?lnk=st&q=Unable+to+copy+file+because+it+is+being+used+by+another+process.+vs+2005&rnum=3&hl=de#62a5440b17e07260

open project properties and edit pre-build events:

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

Posted by orbit3032263 on 3/10/2006 at 2:14 PM

Thanks a lot. The workaround:

http://lab.msdn.microsoft.com/productFeedback/ViewWorkaround.aspx?FeedbackID=FDBK43909#1

helped me a lot. There is only small problem that the assembly have to exists if I want to rename/move it. My version has one if clause more...

open project properties and edit pre-build events:

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

Posted by DanMoseley - MSFT on 6/23/2006 at 3:52 PM

Here's a workaround that seems to have worked for at least one person:

Add a certain property to the project that contains the .resx files. If you open up the project in an XML editor, you can add this property to the first <PropertyGroup> in the project: <GenerateResourceNeverLockTypeAssemblies>true</GenerateResourceNeverLockTypeAssemblies>

-- Dan (msbuild@microsoft.com)

Posted by overbaud on 2/27/2008 at 9:29 PM

Regarding error MSB3021 "Unable to copy file XXXX.dll. The process cannot access the file XXX.dll because it is being used by another process."

I encountered this productivity killing issue and after doing all of the usual:

> Removing references and recreating
> Turning of indexing
> Pre / post compile scripts
> <GenerateResourceNeverLockTypeAssemblies>true</GenerateResourceNeverLockTypeAssemblies>

Found the solution to be:

Changing the assembly name from Security to PSS.Security in the project properties.

It clicked that the error had occured when I changed my assemblies to not have the name space in front of them the night before eg. WAS [Company].PSS.Security.dll CHANGED TO JUST Security.dll.

I changed it back and the x.x.vshost.exe MSB3021 lock was not appearing any more on run. As a further test I changed it back to just Security.dll and it failed again... changed it to Something.Security.dll and it worked again.

Hope this helps find a permanent fix (which really is needed) and a workaround in the meantime.

Scott Pinkerton

Posted by JAMES_DEV on 11/14/2008 at 8:56 AM

In our case the main project is a c++.Net project, so that could be locking it (I think).
If this is the case, is there a c++ equivalent to <GenerateResourceNeverLockTypeAssemblies> and theres no PropertyGroup section to put it in.

Posted by FeedMeAStrayCat on 1/13/2009 at 5:59 AM

Issue I reported with BizTalk Server 2009 Beta in VS2008, with 3 BT Projects and 1 Custom Pipeline, with following Project Dependency and Build Order.

1. Custom Pipeline
2. Pipeline Project <-- Custom Pipeline
3. Messaging Project
4. Processes Project <-- Messaging <-- Pipeline Project

Adding to 'TargetPath.locked' script to the pre-build event of Projects 1,2 & 3 but not 4 worked along with including <GenerateResourceNeverLockTypeAssemblies> tag to csproj/btproj files of all Projects worked.

I also unchecked Enable VS Host Process from Debug Tab on all Projet Properties.

Posted by Roman Korneev on 3/11/2010 at 4:52 AM

Same problem in VS 2008 SP1
Bug not Fixed!

I have Web Application with additional modules

<solution dir>\WebApplication
<solution dir>\WebApplication\Modules\Module1
<solution dir>\WebApplication\Modules\Module2

modules configured in web.config:

.....
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
     <probing privatePath="bin;Modules\Module1\bin;Modules\Module2\bin" />
</assemblyBinding>
</runtime>
<system.web>
<compilation debug="true" batch="false">
    <assemblies>
     <add assembly="Module1"/>
     <add assembly="Module2"/>
    </assemblies>
</compilation>
</system.web>
...

Visual Studio 2008 locks files Module1.dll and Module2.dll even before begin debug WebApplication
To unlock files i change web.confg for example <add assembly="Module1foo"/> and save it. After save Visual Studio unlock file.

Solution from "orbit1" working too
It is bug of Visual Studio and have to be fixed

Posted by Nailuj1 on 6/8/2010 at 12:55 AM

I've had a discussion around this question for some time on StackOverflow: http://stackoverflow.com/questions/2895898/visual-studio-build-fails-unable-to-copy-exe-file-from-obj-debug-to-bin-debug.

After some time with no really useful suggestions, I settled on the "hack" to rename the file in Windows Explorer when I had a build that fails. Today however, drharris came up with a solution that actually seems to work: http://stackoverflow.com/questions/2895898/visual-studio-build-fails-unable-to-copy-exe-file-from-obj-debug-to-bin-debug/2994502#2994502

In short he says: try changing the [assembly: AssemblyVersion("1.0.*")] in AssemblyInfo.cs to [assembly: AssemblyVersion("1.0.0")] (i.e. without the "auto increment" asterisk for build/revision number). His suggestion to why this causes the problem, is "I'm guessing that VS was keeping a handle on each file it generated, so it would know how to increment things", which does sound at least plausible.

I hope somebody at Microsoft can pick up on this, because it obviously is a know problem that has been around for some time!

"MSB3021: Unable to copy file" bug still not fixed in final version by orbit3032263