visual studio keeps locking files - by Dave Smits

Status : 

  Fixed<br /><br />
		This item has been fixed in the current or upcoming version of this product.<br /><br />
		A more detailed explanation for the resolution of this particular item may have been provided in the comments section.

Sign in
to vote
ID 533411 Comments
Status Closed Workarounds
Type Bug Repros 65
Opened 2/13/2010 2:23:14 AM
Duplicates 534247 Access Restriction Public


When developing winforms applicationtargeting .net 3.5 in c# with visual studio2010, visual studio keeps locking an dll or the exe files after a debug session. Because the files are locked it's not possible to work futher because rebuilinding imposseble. 
Sign in to post a comment.
Posted by sveingunnar on 11/27/2014 at 3:55 AM
At them moment I basically have to restart VS every time after a debugging session. Which is greatly impacting my productivity. It is totally random, sometimes I can start a new debugging session straight away, other times the process is locked and I have to restart VS as nothing else helps.
Posted by sveingunnar on 11/27/2014 at 3:36 AM
Happening all the time after VS2013 upgrade. Please reopen.
Posted by Haenles on 10/20/2014 at 2:32 AM
Should definetly not be closed. Issue is still in VS2013 RC3. Please reopen and fix.
Posted by adigostin on 9/17/2014 at 5:07 PM
I switched from 2012 to 2013 a couple of weeks ago and I immediately began getting this bug (and others).
I don't understand why you Microsoft people closed this. I though you "greatly value our feedback"??
Posted by Richard.Haggard on 9/10/2014 at 10:52 AM
Should not be closed. This problem started with VS 2010 and is still present as of VS 12.0.30501.00 Update 2. I see it most often after a debug session has been terminated due to an edit and continue failure to accept a change.
Posted by gabrielmaldi on 7/22/2014 at 6:44 PM
This is still happening on a Console App project in VS 2013 Update 2!
Posted by MyRBC on 5/18/2014 at 7:19 AM
I have the same error in VS Ultimate version 12.0.21005.1 REL. I have received this error several times now. I get the error when I debug my code and stop debugging my code. I receive the error multiple times now. Mange to work around by selecting previous running code; but this is not working either any more...and I ended up here writing to you.

Error 11
Could not copy obj\Debug\xxxx.exe to bin\debug\xxx.exe. Exceeded retry count of 10. Failed.

Error 12
Unable to copy fileobj\debug\xxx.exe to bin\debug\xxx.exe. The process cannot access the file bin\debug\xxx.exe because it is being used by another process
Posted by Rumr Ltd on 2/28/2014 at 6:53 AM
I'm also receiving the same problem. I've got a simple console application using a WCF client proxy. I cannot terminate the console application process. Killing it in Process Explorer seems to restart the process. As a result, I cannot do any further builds as the files are locked.

Visual Studio 2013 (Version 12.0.21005.1 REL)
Posted by Puterdo Borato on 2/18/2014 at 1:41 PM
Happens in VS2013 Update1 all the time with my console app. Please fix, it is a very annoying bug. As Keith said only VS restart helps but then it happens again.
Probably i will downgrade to VS2010SP1, it's my favorite as it works like a charm.
Posted by RKPatrick on 2/13/2014 at 4:13 PM
I get this in VS2013 Update 1 about every other time I try to debug. It's just a simple WCF service and a console app in the same solution. Killing IIS Express doesn't work, nor does Clean/Rebuild, nor does doing anything with AppExperience. Only fix so far is restarting devenv, and I'm REALLY getting tired of doing that every couple of minutes.
Posted by Jon 1001 on 1/17/2014 at 5:48 AM
I have a VS2013 solution containing a WinForms project, a class library, a WPF project and a couple of others. Like Vassilios, I get locking problems on build but not always. When the locking does happen, it always seems to be .pdb of the WPF project that is locked by devenv.exe, preventing the build. I can't be certain, but I think that the problem is triggered by a modification in some XAML or XAML.cs in the WPF project. I can't reliably make it break though, so there must be more to it than that.

Like Vassilios, I can't cure this with a Clean/Rebuild. The only thing that works is closing and reopening VS.
Posted by BSTOH on 12/17/2013 at 10:59 PM
I finally how fix it. Why we can't continue debug after the first debug because the first debug exe still running. So that, after first debug, you need to go to Task Manager -> Process Tab -> [your project name exe] end the exe process.
Posted by Vassilios Pallis on 12/2/2013 at 10:49 PM
Happens at every build with VS 2013 and WPF project. Have to close and reopen VS. Cleaning Solution is not working.
Posted by ct_360 on 11/20/2013 at 11:45 AM
The issue still exists and occurs irregularly with WinForms in VS 2013 (12.0.21005.1 REL) on a fresh Windows 8.1 Pro x64 installation.
I was able to help myself by cleaning the project and solution.
Posted by sdfwill on 11/12/2013 at 11:51 AM
Happening very, very frequently in VS2013.
Posted by eric vsuser on 10/29/2013 at 1:36 PM
This is now happening very often with Visual Studio 2013 also.
Posted by TanyaSolyanik on 9/12/2013 at 7:55 AM
Hello NabMo,
The original bug tracked by this thread was in the Windows Forms designer. Please create a new bug report for the XAML designer and, if possible, provide a project that illustrates the problem or exact steps to create such a project then we will investigate the issue.
Thank you,
Tanya Solyanik, Microsoft
Posted by NabMo on 9/12/2013 at 2:25 AM
This is happening to me and every single time. It happened with VS2012/Windows 8 and now with VS2012/Windows 8.1. XAML designer keeps blocking binary files If I open any XAML file in designer and then make a change. Tried the workarounds but nothing works. I am not using any of the extensions.
Posted by Hunain Durrani on 8/26/2013 at 5:16 AM
I am also facing the same issues but it occured all of a sudden, I was able to compile the codes wıthout any problem. I request Microsoft to solve this issue.

Posted by robinwilson16 on 6/24/2013 at 4:16 AM

I am having this issue as well every time I try to compile a program in VS2012 Update 2 if it crashes and the only solution seems to be to restart the computer all the time to remove the locks from the files to I can re-compile.
I can see this is closed as fixed but I cannot find the fix. I have all the updates installed, am I missing something?

Posted by Marco [MSFT] on 5/28/2013 at 7:52 AM
I am sorry to hear that you still experience this problem with VS 2012. If you could please provide us with a project that illustrates the problem then we we would be able to investigate the issue.
Posted by LaWay on 5/15/2013 at 5:45 AM
It is not fixed. Got the same problem on Visual Studio 2012 v11.0.60315.01. Please reopen.
Posted by Richard Deeming on 4/9/2013 at 4:37 AM
This bug is NOT fixed. It still affects Visual Studio 2012.2 (11.0.60315.01).
Posted by warmac on 4/2/2013 at 6:42 PM
This gave me back my sanity. Days I spent on this file lock and slow VS 2010 issue only to find a solution that took minutes.
Posted by Tlford on 3/19/2013 at 4:48 PM
It happens every time I debug a WPF project. Please re-open! I have to close VS and re-open to start debugging again.
Posted by Stephen Drew on 1/22/2013 at 2:24 AM
This is not fixed, still get it inside VS2012:

27>C:\Windows\Microsoft.NET\Framework\v4.0.30319\Microsoft.Common.targets(3363,5): warning MSB3026: Could not copy "XXX.dll" to "XXX.dll". Beginning retry 10 in 1000ms. The process cannot access the file 'XXX.dll' because it is being used by another process.
27>C:\Windows\Microsoft.NET\Framework\v4.0.30319\Microsoft.Common.targets(3363,5): error MSB3027: Could not copy "XXX.dll" to "XXX.dll". Exceeded retry count of 10. Failed.
27>C:\Windows\Microsoft.NET\Framework\v4.0.30319\Microsoft.Common.targets(3363,5): error MSB3021: Unable to copy file "XXX.dll" to "XXX.dll". The process cannot access the file 'XXX.dll' because it is being used by another process.
Posted by TanyaSolyanik on 11/5/2012 at 3:49 PM

Do you have any extensions installed, if yes, could you please see what happens when they are disabled?
Thank you,
The Windows Forms Product Team
Posted by Tanya [MSFT] on 11/5/2012 at 9:30 AM
Hi Daniel,

We were unable to reproduce the bug with the project included in the original report. However we would like to understand this issue better. Could you please open a new bug report and describe your project and project dependencies or attach a project which reproduces the issue.
Thank you,
The Windows Forms Product Team
Posted by Daniel_ngn on 11/4/2012 at 11:18 PM
My God, I'm seeing this issue on my VS2012 as well. Windows 8 actually kindly report that the output file is being locked by Visual Studio XAML UI designer. None of the workaround is effective for me. This is such a nightmare that keeps on and on!
Posted by Niels Bos on 5/8/2012 at 1:41 AM
Arg, never mind, I misread the thread. Thanks:)
Posted by Niels Bos on 5/8/2012 at 1:39 AM
I see the issue is over one year old and marked as fixed. Is the release with the fix out yet, because I have this issue in my up-to-date vs2010 as we speak, making development extremely slow as I need to restart visual studio every 2-5 minutes to release the dll.
Posted by Microsoft on 2/25/2011 at 5:05 PM
Hello All -

Thank you very much for the continued feedback. Some of you have reported that the workaround mentioned in this bug does not work. We would like to investigate this issue further so we have opened a separate Connect bug. If the workaround does not work for you, please visit Connect Bug #647826 to participate in this investigation: If the workaround does work, you can expect a fix for the issue in the upcoming Service Pack 1 for VS2010.

Thank you again,
The Windows Forms Product Team
Posted by tesko905 on 2/24/2011 at 12:50 PM
Is this issue fixed in VS2010 SP1 Beta? Also, any details on RTM release date?
Posted by skimania on 2/24/2011 at 7:52 AM
So, yup neither the workaround nor removing that reference fixed my problem.

This is not good guys!
Posted by skimania on 2/24/2011 at 6:23 AM
While testing this bug, I came across a problem similar to this one and found that my Controls.dll project was referencing itself! Why would VS allow this? I know I didn't set it...

Still not sure if my problem is fixed yet.
Posted by skimania on 2/24/2011 at 6:14 AM
I am also experiencing this problem. I have a large WinForm solution recently converted from VS2005 to VS2010. I've got a WinForms.exe referencing a Controls.dll library. Occasionally, I cannot rebuild the Controls library because VS2010 can't copy the dll from the obj\debug to bin\debug.

This is an unacceptable bug and if it's not actually fixed, why is it marked as such in your tracker?

I'm running VS 10.0.30319.1 RTMRel

Please let me know if I am running the correct version to have the fix and if so then why am I experiencing it.

Posted by Jonathan Willis on 2/17/2011 at 8:08 AM
This bug is not fixed. I've been ripping my hair out the last 3 weeks thinking it was something in my code.

I have VS2010 from a clean install, and fully updated.

I can confirm the issue happens when you launch debug if a custom user control is open. The only work around I have is to close it before debug and if you forget then restart visual studio.
Posted by NetMage on 2/4/2011 at 11:01 AM
I don't believe this should be closed either. I have the same issue in VS2010 SP1 and have taken to disabling VSHOST in project debug options in order to be able to debug at all.
Posted by TBittlingmayer on 1/14/2011 at 3:48 AM
I don't understand why this is closed. I can reproduce the issue as often as I want. Is there a hotfix or something? The workaround stated here as well as any other workaround I've read about (concerning also the prior vs versions) don't work. AFAIC, the situation with file locking got even worse since VS2008.

I'm really annoyed with buying a software for a few thousand €'s (since years) and having such simple problems persisted in all versions. There must be a way to fix it, assuming that anybody at MS understands the problem.

Contact me if any help in reproducing the issue is needed, I can show it in VS2005, VS2008 and VS2010.
Posted by MarkJuras on 1/13/2011 at 6:22 PM
This was not a problem in VS2008, but it is still a problem in VS2010. The workaround does not work.
Posted by JohnHorb on 12/30/2010 at 2:00 AM
Not sure why this is closed. Some people have indicated that the WORKAROUND doesn't help, and in any case, it is ONLY a workaround.
Posted by Roger Meddows Taylor on 12/20/2010 at 12:47 PM
Indeed this is smth that is very nasty and annoying, I've tried workaround and it didnt help. Please can I have a hotfix?
Posted by Matt Grove on 12/18/2010 at 4:27 PM
Can we please get a fix for this bug? It's definitely related to the VS hosting process. I've tried to kill that process, but it either doesn't die or it pops up immediately again (I'm not sure which). In any event, that doesn't help.

I'm doing pure WPF development, so yes, I have the XAML editor open constantly. I'm not using "*" build versioning. The locks in question are on a DLL that contains (WPF) controls.

I'd take a hotfix at this point.
Posted by Steffen Mangold on 12/14/2010 at 3:57 AM
Wildcard think dont have effect.
I use "buildversionincrement" addon and the same problem without using wildcards.

Posted by Estyfen Alzate on 10/4/2010 at 6:55 PM
Already attached files, project and the steps that can reproduce the error.

Thank you very much
Posted by Estyfen Alzate on 10/4/2010 at 6:54 PM

Already attached files, project and the steps that can reproduce the error.

Thank you very much
Posted by Ldcroberts on 8/26/2010 at 2:02 PM
I agree with Michael, having local user controls on a form loaded in the designer seems to lock it for me too.
Posted by Dave Smits on 7/30/2010 at 6:22 AM
as microsoft said, issue will be solved AFTER the rtm release.
Posted by nqk on 7/21/2010 at 3:58 AM
Please re-open this, VS 2010 RTM still has this bug. As I need to auto increment my AssemblyVersion, the workaround is not appropriate.

appname.vshost.exe even reappears after killing it using the Task Manager! So a restart of Visual Studio is required.
Posted by Michael Lee Yohe on 7/13/2010 at 9:13 AM
I believe this bug is caused using controls developed in project assemblies that are built along side any projects that use those controls. The problem seems to be more profound when using quite a few controls that are interdependent with quite a few projects. I have also witnessed this problem when using controls developed within a single project file. This tells me that the designer itself is not properly disposing the controls and releasing the handles to the built assemblies that those controls reside in.

The easiest way I've been able to reproduce this bug (which now happens in a 5 to 10 minute interval at the stage of development I am in a very large project I am working on currently) is as follows:

1) Create a Windows Forms solution with a single form (project #1).
2) Create a new user control project (project #2) and add to the solution.
3) Create two user controls in project #2 and add image boxes to the controls.
4) Create a single user control in project #2 that contains both of the user controls created in step 3.
5) Create a single user control in project #1 that contains all three controls from project #2 (user control should contain the three created user controls in project #2).
6) Add the user control from project #1 to the Windows Forms application.
7) Build, run, and close the application.
8) Go back to project #2 and modify the position of the image boxes and assign arbitrary images to the controls.
9) Add a label control and alter its text.
10) Repeat step 7-9 until you get the process lock bug.

After the first build (or the next few builds), the designer seems to hang on to the built assembly for project #2 without releasing it. When you encounter the bug, attempt to do as follows:

1) Close all open designer tabs.
2) Rebuild solution [bug will be encountered].
3) Close the solution and reopen it.
4) Rebuild solution [bug will be encountered].

At this stage, the only method to continue is to exit the VS2010 process entirely and restart. I have disabled any and all extensions added to VS2010 to see if this helps - and it does not.

I agree with the original reporter's assessment (also using the same tool to investigate) that VS2010 does not release the assembly as it should upon rebuild, close of the designer for a given form, or the entire closure of the solution. VS2008SP1 did not exhibit such issues.

My solution is solely .NET 4.0 - so the framework target does not seem to relevant to the underlying cause of this problem.
Posted by Michael Lee Yohe on 6/18/2010 at 11:51 AM
This should be re-opened as RTM VS2010 still exhibits this issue.
Posted by WestyOz on 6/1/2010 at 3:21 PM
I can confirm that in the RTM version of VS2010, the bug is still present. It has taken me the best part of a day to stumble upon this particular feedback item. Implemented workaround and can now build without experiencing file locks. Any word on when this one is going to be resolved properly?
Posted by Dave Smits on 3/18/2010 at 1:13 AM
nice to hear! sad that the fixes comes after the rtm, is there an indication how long after the rtm the fix will be available?
Posted by Tanya [MSFT] on 3/17/2010 at 1:43 PM
This bug will be fixed post Dev10 because at this point in the product cycle the fix might destabilize the product.

Note that the workaround is to not increment the assembly version after a rebuild or to close the designer window before the rebuild.
Posted by Dave Smits on 3/15/2010 at 11:05 AM
it looks like it works. no need to reset visual studio anymore.
Posted by Dave Smits on 3/6/2010 at 4:30 AM
i will try it out! hope it helps because it really annoying to restart VS after almost each debug session
Posted by Tanya [MSFT] on 3/5/2010 at 1:18 PM
Temporary workaround would be disable assembly version update after the rebuild. In AssemblyInfo.cs file, remove the wild card from the AssemblyVersion attribute, for example:
replace this:
[assembly: AssemblyVersion("1.4.*")]
[assembly: AssemblyFileVersion("1.4")]
with this:
[assembly: AssemblyVersion("")]
[assembly: AssemblyFileVersion("")]

Posted by Andrew [MSFT] on 2/24/2010 at 5:45 PM
There is a known bug where the XAML editor can cause this, routing to that team for invesitgation.
Posted by Dave Smits on 2/23/2010 at 11:51 PM
also here it looks not to happen when when i create a small app. Are there some log files or something? its really annoying. Sometimes i need to restart visual studio every 10 minutes.
Posted by Dave Smits on 2/21/2010 at 11:58 PM
looks i found the issue. I'm using nhibernate and when i terminate the program while i'm using a nhibernate session and not yet disposed it the assembly that have opened the nhibernate session is locked. I will try to make a small example
Posted by Dave Smits on 2/21/2010 at 9:38 AM

Yes the solution contains a wpf project but that project isn't involed, just a tryout project.

I still trying to isolate the issue but at this moment i don't have it yet. I can send my total project but that is 28 projects (including test projects).
Posted by Andrew [MSFT] on 2/19/2010 at 2:24 PM
Hello, one more question. Does your sample project contain any xaml files?
Posted by Andrew [MSFT] on 2/19/2010 at 11:39 AM
Hello, please upload the sample as soon as possible
Posted by Microsoft on 2/15/2010 at 8:54 PM
Hi Dave,

Thank you for reporting this issue.
But we're unable to reproduce this issue. We really need to get more information from you to reproduce it. If you finish your small project, please upload it as soon as possible.

Thank you,
Visual Studio Product Team.
Posted by Dave Smits on 2/15/2010 at 4:05 AM
when i need to provide more info let me know! This is really very annoying bug. Need to restart visual studio 2010 rc1 almost after each debug session! I can provide a solution (it's not a small project, i will try to make a small one to reproduce)
Posted by Microsoft on 2/13/2010 at 7:09 PM
Thank you for your feedback, we are currently reviewing the issue you have submitted. If this issue is urgent, please contact support directly(