none
Unable to copy file -> restart VS2010 after each debuging session

    Question

  • The bug in this thread from the beta/rc is not resolved: http://social.msdn.microsoft.com/Forums/en/vstsprerelease/thread/3b523bcd-9f28-41d2-af18-4aa9445c85c1

    I'm still getting locked files and the message "Unable to copy file..." when compiling after debugging (Winforms app, VS2010Pro on Vista7 64-bit, CoreI7, 8 GB Ram)

    Any ideas?

     

    Thursday, April 15, 2010 6:08 PM

All replies

  • What happens if you disable the hosting process (Project Properties -> Debug | uncheck "Enable the Visual Studio hosting process")?
    Best Regards, Andrew Hall. Visual Studio Debugger.
    Saturday, April 17, 2010 12:51 AM
  • Also, is there any chance you could provide us with a sample project that reproduces this problem?
    Best Regards, Andrew Hall. Visual Studio Debugger.
    Saturday, April 17, 2010 1:09 AM
  • The source code is here: http://www.nikse.dk/se/SE29Source.rar

    I'm debugging the form "FixCommonErrors" (no pun intended ;) and sometimes I get the error when I terminate the debugging, fixes some code and compile.

    >What happens if you disable the hosting process (Project Properties -> Debug | uncheck "Enable the Visual Studio hosting process")?
    I still get the error.

    Best regards, Nikolaj

    Saturday, April 17, 2010 7:26 AM
  • Thank you, I will take a look and let you know what I discover
    Best Regards, Andrew Hall. Visual Studio Debugger.
    Monday, April 19, 2010 8:58 PM
  • Nikolaj,

    Thank you very much for the project, we were able to reproduce this problem.  We have passed the project and repro along to the appropriate team inside Visual Studio and I will let you know once the investigation is complete.


    Best Regards, Andrew Hall. Visual Studio Debugger.
    Wednesday, April 21, 2010 12:40 AM
  • Thx, sounds good!

    Best regards
    Nikolaj

    Wednesday, April 21, 2010 4:56 AM
  • It turns out that this is a bug in the Windows Form designer.  There are two workarounds for this until a fix is released by the Windows Forms team:

    1.  Close the form designer when editing .cs/.vb files, just have the code files open

    2.  For your project, in "Properties\AssemblyInfo.cs" comment out the [assembly: AssemblyVersion(....)] line of code.  If your final project requires correct versioning remember to uncomment this line afer you are finished development.


    Best Regards, Andrew Hall. Visual Studio Debugger.
    Thursday, April 22, 2010 11:39 PM
  • That was fast, thx!

    I will use step 2 until a fix comes out.

    Best regards, Nikolaj

     

    Friday, April 23, 2010 5:15 AM
  • Is there a status on this? It seems like a fairly glaring/horrible bug and will most likely lead me to go back to VS2008.

     

    The first stated workaround can only prevent the issue from arising. Closing the designers will not "fix" the issue within a VS instance without a restart. The second workaround will break our licensing mechanisms effectively preventing us from running our project at all.

    Tuesday, May 18, 2010 5:25 PM
  • Yes, please fix this soon. I get tired of restarting VS2010 100+ times a day.
    Sunday, May 23, 2010 10:30 PM
  • Neither of the two fixes proposed by the WinForms team work (as indicated by @Dakka314) for similar restrictions.  This problem seems to be exacerbated by the presence of project assemblies that provide controls that are in-use by a foreign project assembly.

    I've been actively following the Microsoft Connect bug in which the WinForm team has flagged the bug as fixed (pre-RTM).  No further word from the Microsoft team on reopening or revisiting this issue.

    https://connect.microsoft.com/VisualStudio/feedback/details/533411

    Is there another Connect reference to this bug where Microsoft is communicating the status of this issue and possibly providing a hotfix in the interim?

    Friday, July 02, 2010 4:24 PM
  • As noted by others above, this is an excruciating issue. Coupled with other slowdowns we're seeing in VS 2010, we're likely to downgrade to 2008 unless a hotfix is released. Please provide an update on this.
    Monday, July 05, 2010 2:00 PM
  • Deleting the screwed up .suo file that is in the same directory as the .sln file solved the issue for me. I think this file contains user settings that got confused somehow...

     

    greetings

    Philipp

    • Proposed as answer by aurealus2 Friday, July 23, 2010 5:41 PM
    Friday, July 09, 2010 12:37 PM
  • Same here.. Deleting the .suo fixed the problem.
    Monday, July 19, 2010 2:54 PM
  • Deleting the .suo fixed the problem for me also.
    Friday, July 23, 2010 5:42 PM
  • Deleting the .suo file does NOT work for me :(
    Thursday, July 29, 2010 8:29 AM
  • Same here, neither commenting the Assemblyversion, nor closing the form, nor deleting the .suo file helped. Somewhat stuck with VS2010 here
    • Proposed as answer by MovingForward Thursday, August 12, 2010 12:55 AM
    Tuesday, August 03, 2010 9:37 AM
  • Sorry guys, pressed the wrong button and "Proposed As Answer" to Andreas Nicklas was incorrect.

    However, after suffering this VS2010 issue to too long, and NEVER knowing when to expected it, I tried all the above suggestions. This is what worked (and what didn't) for me:

    • The commenting out of "AssemblyVersion" in AssemblyInfo.cs did NOT help
    • Closing the designer form did not help
    • Killing the SUO did NOT help - in the same VS2010 session

    BUT

    • Killing the SUO outside the VS2010 session (i.e. exit the VS2010 first) WORKED - at least for now.

    I have been programming for many years, since the Microsoft C compiler came on three floppy discs :-) and never encountered such an irritating bug, and one that does not seem to be being addressed by Microsoft.

    Hey guys in Seattle, or whereever you are, wake UP.

    • Proposed as answer by davide.cuppone Saturday, October 22, 2011 9:11 AM
    Thursday, August 12, 2010 1:07 AM
  • At first I only received this error occasionally, but the locks are retained indefinitely, until the app is closed. If you don't want to restart VS to keep going, you can rename the old output file and keep going, but after running VS for a day or so without restarting it I had racked up 4 or 5 file locks. 

    I restarted VS but not long after that I got the error again but it began happening constantly, as in one good build, next build fails, rename the file, one good build, next build fails. 

     

    Closing VS, deleting the SUO and restarting seemed to work for me.

    Saturday, August 14, 2010 7:27 AM
  • I have the same problem.

    But closing VS and deleting the .suo file does not work for me. I tried several times.

    There is also no WinForms designer involved. My projects are pure WPF applications/libraries.
    I currently do not use signing

    I get the problem always with exactly one of my assemblies. The .dll and .pdb files are locked by the .vshost.exe process.
    It gets locked directly after launching VS, so the 1st build fails already. There is nothing special about this assembly.
    It's a simple WPF UserControl library with a Window, a UserControl, 2 WPF ResourceDictionaries and several native C# classes

    Disabling the VS hosting process for the project works but this slows down the debugging and testing process a lot.

    I can not see a real difference between this assembly which causes the problem and some other verry similar assemblies, which get not locked.

    Friday, September 03, 2010 7:34 AM
  • This is an incredibly irritating bug...I've tried all the workarounds mentioned here and none of them seem to provide a permanent solution.

     

    I'm sure glad I downloaded the 2010 trial before diving in and buying it...considering this bug has been around for 5 months with no real resolution (hotfix), I'm pretty much ready to roll everything back to 2008.

    Monday, September 27, 2010 4:37 AM
  • I totally agree. This bug should be on the top of the list to fix. Apparently its not. How hard can it be to fix this one? It's easy to duplicate. There are known workarounds. Come on guys...r u kidding? You need me to come over to Redmond and help you out? 
    Wednesday, September 29, 2010 4:17 PM
  • Please don't understand me wrong. It's not that I want to say that this bug does not need to be fixed soon.

    But if I look through this thread (and others around the internet) I get the feeling that this problem is caused by many different situations.

    I'm a software developer by my self (as most of you are as well I think), and I know that posts like the last ones do not help anyone.
    I also know that it's a hard job to fix bugs like this one.
    Couldn't you just provide the information which describes exactly your problem and which workaround works for you.
    Then you can add your disapointment that this bug does not get fixed for so long in a gentle way as well.

    That is just my opinion how this forum should work, so if you disagree with me, then ignore me.

    Reinhard.

    Thursday, September 30, 2010 8:26 AM

  • I also know that it's a hard job to fix bugs like this one.

    Couldn't you just provide the information which describes exactly your problem and which workaround works for you.
    Then you can add your disapointment that this bug does not get fixed for so long in a gentle way as well.

    The thing here is that we're not talking about some individual programmer, we're talking about the biggest multi-billion dollar software giant in the world.  Visual Studio is one of their flagship products, the development kit that's used to create the vast majority of software products for the most widespread operating systems in the world.  They charge hundreds of dollars for a single license.  The fact that a bug this crippling has existed for months and they still haven't addressed it is inexcusable; They have *thousands* of programmers and billions of dollars at their disposal, and could easily prioritize this if they wanted to.

    "It's a hard job to fix bugs" maybe relevant to small-time programmers like you and I, but it's neither valid or relevant in light of the above.

    Thursday, October 14, 2010 10:56 PM
  • Just ran into this bug as well... VS2010 Pro - 10.0.30319.1 RTMRel.

    My C# project isn't big or complex at all as I just started it last week.  I was quite baffled as to what I did to the code to make the dev environment get screwed up like it did!  I spent about 6 hours trying to figure it out and it turns out it wasn't my fault!

    Thanks to your suggestions - deleting the .suo with the devenv closed worked for me, nothing else did.  Please fix this bug and send out a patch!

    Wednesday, November 24, 2010 5:28 AM
  • I'm posting to keep this thread up and to note that I am experiencing the same problem.  One other indicator I get is each form I open, opens right up with the asterick as if it has already been modified when I have not touched a thing.

    I'm running VS2010 Premium 10.0.30319.1 RTMRel.

    One last note: I have lost more than a few development hours due to this bug and a few other credited to the designer.

    Friday, November 26, 2010 1:16 AM
  • Keeping the designers closed seems to work for me, although it's ridiculous to think that's a solution.
    Friday, November 26, 2010 8:53 PM
  • I am also experiencing the same problem: file locked and I am unable to start debug session. Target file is locked by system process. I am using Windows 7 64Bit. Same project looks working fine on my older machine with Winxp 32bit.

     


    Leo
    Sunday, December 05, 2010 3:29 PM
  • Maybe this link will be usefull: http://nayyeri.net/file-lock-issue-in-visual-studio-when-building-a-project

    Pre-build steps solution works for me.

    Friday, December 10, 2010 9:26 AM
  • Brand new project,  two forms, and I am getting the same error "Unable to copy file..........." . I am using Windows 7 64Bit. Close one of the form designers and and project builds. Microsoft, please can we get a fix
    Sunday, January 16, 2011 10:30 AM
  • This bug has existed in VS for the last 5 years,  http://social.msdn.microsoft.com/Forums/en/msbuild/thread/6f76db9a-ea37-42b3-a016-571912c28032

    Microsoft clearly doesn't care and never will.

    Monday, January 31, 2011 3:16 PM
  • I've tried both solutions provided by you, but nothing seems to work.

    DO you have any other suggestion ? 

    Wednesday, March 23, 2011 2:14 PM
  • Probably this may help you

     

    Go to the Project Property window

    Go to Build 

    Copy following line to Pre-Build Event

     

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

     It simply copies the locked file to a new location and lets your build process to be followed.

    Wednesday, March 23, 2011 2:28 PM
  • This issue cropped up for me a few days ago, and I have SP1 installed. Deleting the .\bin\ and .\obj\ dirs fixed the problem - for a day. Deleting the .suo file just clears my configured workspace, which is a PITA.

     

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

    I don't have any .locked files, so this fix doesn't help me.

     

    I started another thread at http://social.msdn.microsoft.com/Forums/en-US/vsdebug/thread/7a47efb6-047a-4d14-83de-93bbea1d002c before I found this one.

    Wednesday, March 23, 2011 3:09 PM
  • My project was on a network drive, and I moved it to my local drive, and the debugging problems have stopped. (I moved it because of another network drive-related bug due to problems with the designer displaying XAML pages when using a local schema.) Sounds like it could be related.
    Tuesday, April 12, 2011 3:01 PM
  • Something that worked for me is the following:

     

    Basically, run Visual Studio 2010 as an administrator.

     

    Close Visual Studio 2010 if open.

    Right click the Visual Studio 2010 propgram icon and select Properties.

    Open the Compatibiliity tab.

    Check the 'Run this program as an administrator' checkbox.

    Restart Visual Studio 2010.

    Tuesday, June 21, 2011 12:46 PM
  • Hey Guys - I've been experiencing this problem for far too long now.  Most of my development is done against DLL's, and not EXE's, but every now and then I get a wild idea and try to write a helper console app.  I can repro every time - first build is OK, next build output files are locked.  No changes to code, no errors, didn't run the file, nothing.  Nada.  File is locked.  If I restart and delete, the file will come back.  If I permanently delete it, the file will come back.  If I try to compile my console app using csc.exe, same issue.  When I build, VS2010 gives me the error:

    Error 1 Unable to copy file "obj\x86\Debug\foo.exe" to "bin\Debug\foo.exe". The process cannot access the file 'bin\Debug\foo.exe' because it is being used by another process. foo

    If I manually delete the file, it reappears after I refresh the folder.  If I delete the file and restart, it reappears.  If I wait about 20 minutes, it'll finally delete and I can do another build.

     

    Here's my system:
    Windows 7 Professional x64 on Dell T3500, quad core + HT, 12gigs RAM.
    Visual Studio 2010 (10.0.40219.1 SP1Rel)
    (only have C# 2010 installed)
    Crucial C300 256gb SSD
    Latest windows updates (required by group policy)
    Directory permissions are OK (problem happens on any drive, any folder, etc)
    SSD is running under latest Intel AHCI driver.

    I can repro by creating a new, empty console app and trying to rebuild it multiple times and/or launching the debugger.  There are no special libraries, templates, etc that are modifying my project or binaries.  Virus scanner is turned off, no backup drives or software, no viruses (full scan), no adware (or corporate network is pretty tight).  This is my work system and I spend my days writing web apps in C#.

    Creating similar functionality in JScript + CScript.exe can get me by for most issues, but it's a more time consuming language for me.

    Is there any hot fix or anything I can do?

     


    Friday, July 15, 2011 11:03 PM
  • We recently converted from Visual Studio 2008 to Visual Studio 2010. We got a huge n-tier application that uses different libraries and solutions, using Wpf as frontent technology.

    In 2008 I could have multiple solutions (Visual Studio's) open without any issues. In 2010 I can have only 1 solution open and after every comile action I have to close all my xaml files do a Build -> Clean Solution and a new compile action to prevent this file-lock issue. This is really slowing down our development and has a huge annoyance factor. How can Microsoft haven't fixed this issue after 16 months or so.

    And btw none of the proposed workarounds:

    • using VsCommands
    • removing AssemblyInfo versioning
    • using a prebuild copy action
    • disabling step-through
    • disabling the vshost process

    gives a permanent solution to this issue.

    Tuesday, July 26, 2011 8:02 AM
  • We recently converted from Visual Studio 2008 to Visual Studio 2010. We got a huge n-tier application that uses different libraries and solutions, using Wpf as frontent technology.

    In 2008 I could have multiple solutions (Visual Studio's) open without any issues. In 2010 I can have only 1 solution open and after every comile action I have to close all my xaml files do a Build -> Clean Solution and a new compile action to prevent this file-lock issue. This is really slowing down our development and has a huge annoyance factor. How can Microsoft haven't fixed this issue after 16 months or so.

    And btw none of the proposed workarounds:

    • using VsCommands
    • removing AssemblyInfo versioning
    • using a prebuild copy action
    • disabling step-through
    • disabling the vshost process

    gives a permanent solution to this issue.

    • Proposed as answer by PijushBiswas Tuesday, July 26, 2011 1:21 PM
    • Unproposed as answer by PijushBiswas Tuesday, July 26, 2011 1:21 PM
    Tuesday, July 26, 2011 8:03 AM
  • I found a workaround

     

    Go to task manager->find out  ASP.NET Development Server (on which the web site is hosted for debugging)->Right Click->Click on End Process

     

    This will remove the compile error and next time you start debugging, same process will be loaded in task manager

     

    Thanks

    Pijush Biswas

     

     

    Tuesday, July 26, 2011 1:24 PM
  • Sorry guys, pressed the wrong button and "Proposed As Answer" to Andreas Nicklas was incorrect.

    However, after suffering this VS2010 issue to too long, and NEVER knowing when to expected it, I tried all the above suggestions. This is what worked (and what didn't) for me:

    • The commenting out of "AssemblyVersion" in AssemblyInfo.cs did NOT help
    • Closing the designer form did not help
    • Killing the SUO did NOT help - in the same VS2010 session

    BUT

    • Killing the SUO outside the VS2010 session (i.e. exit the VS2010 first) WORKED - at least for now.

    I have been programming for many years, since the Microsoft C compiler came on three floppy discs :-) and never encountered such an irritating bug, and one that does not seem to be being addressed by Microsoft.

    Hey guys in Seattle, or whereever you are, wake UP.

    This worked, and I agree with you it's very irritating, something you don't expect from VisualStudio
    Saturday, October 22, 2011 9:14 AM
  • We've experienced this issue as well, when async methods in our test project were throwing exceptions. In your Unit Tests, make sure you subscribe to the AppDomain's UnhandledException event to catch these exceptions so that they don't cause MsTest to keep its stuff lying around.

    http://stackoverflow.com/questions/3529917/nunit-secondary-thread-exception


    My blog: blog.jessehouwing.nl
    Monday, November 28, 2011 9:09 PM
  • Try this:

    1. close VS

    2. go to task manager

    3. check off "Show process from all users"

    4. go to the task <name>.vhost.exe *32

    5. kill the task

    6. delete the bin folder


    • Edited by thcst81 Thursday, January 19, 2012 4:33 PM
    Thursday, January 19, 2012 4:32 PM
  • Solution for Unit test scenario....

    For me the issue came when i execute the Unit test project "Run Test" while the "Debug Test" doesn't cause such issue.

    None of the above workaround solved my problem except for killing the Test agent process.

    Used the below command in pre-build event of test project

    taskkill /f /im QTAgent32.exe

    • Proposed as answer by AustinAjit Saturday, April 28, 2012 8:45 AM
    Saturday, April 28, 2012 8:45 AM
  • There is a post-sp1 hotfix which should solve this error. I'll have to check the exact kb nr on tuesday when \i'm back in the office, but I think it's this one:

    https://connect.microsoft.com/VisualStudio/Downloads/DownloadDetails.aspx?DownloadID=36847


    My blog: blog.jessehouwing.nl

    Saturday, April 28, 2012 9:16 PM
  • Thanks. will look at this. Win7 x64 (w/x64 & x86 n tier) and it it is a major efficiency hit.

    as a work around i rename the object--while process X has a lock on file ABC, and thus while I can't delete ABC, there is no policy in place that prevents me from renaming it to ABC_D.

    after the file is renamed vs2010 will build the file.  usually, within a few minutes, the lock is released and i can go back later and clean the offending deliverables manually.

    i have noted this file lock retention tends to happen on aborted processes: exceptions, ctrl+breaking while developing.  A natural exit *tends* to not reproduce this issue.

    i don't really want to run vs2010 as admin as that could lead to other issues.

    if it is fixed that would be great news.

    Friday, August 31, 2012 12:55 PM