Problem building

Question

I'm developing a fairly largish project in VS2005. A problem I'm having at the moment is that it intermittently displays the error

“Unable to copy file ‘obj\Debug\xxx.dll’ to ‘bin\Debug\xxx.dll’. The process cannot access the file 'bin\Debug\xxx.dll' because it is being used by another process.”

Which is strange because the only process that has control of that file is Visual Studio. I was just wondering if anyone has come across this before, how they solved it and why it occurred? The xxx dll is used by other dlls say yyy and zzz but they’re not used outside of the solution, and nothing else other that the dlls within the solution uses xxx.

Answer 1

I have been successfully using VS 2005 Beta 2 (VB.NET) for about a month now.  Yesterday, I started getting the error:

Error 5 Unable to copy file "obj\Debug\BO.dll" to "bin\Debug\BO.dll". The process cannot access the file 'bin\Debug\BO.dll' because it is being used by another process. C:\WINDOWS\Microsoft.NET\Framework\v2.0.50215\Microsoft.Common.targets 2274 9

This error does not occur the first time I build the solution after just opening it in VS.  But all subsequent build attempts fail with this same error.  If I exit VS and reopen the project then I can again build one time and all subsequent attempts fail with the same error.  Using SysInternal's Handle program, I was able to determine that the only process that had bo.dll open was devenv.exe. 

Additionally, sometimes after I reopen VS and the build successfully completes, when the project starts to run, I get this:

System.InvalidOperationException was unhandled
  Message="An error occurred creating the form. See Exception.InnerException for details.  The error is: Item has already been added. Key in dictionary: 'System.Runtime.CompilerServices.CompilerGeneratedAttribute'  Key being added: 'System.Runtime.CompilerServices.CompilerGeneratedAttribute'"
  Source="EMExcelNet"
  StackTrace:
       at Boeing.D254.EMLab.EMExcelNet.UI.My.MyProject.MyForms.Create__Instance__[T](T Instance) in 17d14f5c-a337-4978-8281-53493378c1071.vb:line 180

       at Boeing.D254.EMLab.EMExcelNet.UI.My.MyProject.MyForms.get_MainForm()

       at Boeing.D254.EMLab.EMExcelNet.UI.My.MyApplication.OnCreateMainForm() in C:\Development\EMExcelNet\EMExcelNet\My Project\Application.Designer.vb:line 35

       at Microsoft.VisualBasic.ApplicationServices.WindowsFormsApplicationBase.OnRun()

       at Microsoft.VisualBasic.ApplicationServices.WindowsFormsApplicationBase.DoApplicationModel()

       at Microsoft.VisualBasic.ApplicationServices.WindowsFormsApplicationBase.Run(String[] commandLine)

       at Boeing.D254.EMLab.EMExcelNet.UI.My.MyApplication.Main(String[] Args) in 17d14f5c-a337-4978-8281-53493378c1071.vb:line 76

       at System.AppDomain.nExecuteAssembly(Assembly assembly, String[] args)

       at System.AppDomain.ExecuteAssembly(String assemblyFile, Evidence assemblySecurity, String[] args)

       at Microsoft.VisualStudio.HostingProcess.HostProc.RunUsersAssembly()

       at System.Threading.ThreadHelper.ThreadStart_Context(Object state)

       at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)

       at System.Threading.ThreadHelper.ThreadStart()

Any ideas on what this exception is about?  It's not in my code.

After working for several hours attempting to resolve these problems, I finally gave up and completely rebuilt my solution and the problems went away for the remainder of the day.  This morning the problems are back again.  Does anyone have any clues as to what is going on here and how I might fix it?

Answer 2

Hi there,
    I had the same problem at work. It only happened occasionally but it was a
    pain in the backside.
    I found the solution by accident.
    You have to turn off Indexing Services on your computer.
    It should be under 'Services and Applications' in Computer Management.
    Right click on 'My Computer' and select 'Manage' from the context menu.
    Alternatively, you can add a directory to
         'Indexing Services..System..Directories'
    And specify that the directory is to be excluded from Indexing Services.
    The directory that you want to exclude is the 'bin' directory of your project.
    Hope this helps.

Answer 3

Thanks for the information!

This morning I have not had the problem.  The next time that the problem arises, I will turn off indexing on my development directory and see what happens.

Thanks again!

Answer 4

Unfortunately, this did not solve the problem.  When this issue arose again today, I stopped the Indexing service, closed VS 2005 Beta 2, restarted it and tried to build again.  The result was the same - the DLL was still in use by devenv.exe.

-Brian

Answer 5

I am using VS2K5 for a WinForm app that has lots of referenced dlls (Projects were upgraded from VS2K3). I have excluded the paths from the index service and Anti-virus software and made all the references CopyLocal = False in all projects except the Forms project.

I consistently get this error every time there is an exception in one of the referenced dlls. There may be other times I get the error, but that is the main cause. The application thread is not running at the time.

Having to continually close and reopen the solution is a real pain. Does anyone from MS have an update on this issue?

Really bothers me that this problem does not seem to be mainstream!

Answer 6

Do you have any custom MSBuild tasks as a part of the solution?

Sayed Ibrahim Hashimi
www.sedodream.com

Answer 7

No. I'm not sure I'm in the right forum. Essentially when in VS2005 and I hit build or rebuild then it will come up with that message. The only way to get rid of it is to exit VS2005, delete the bin and obj directories open up the solution again and then rebuild, until it breaks again.

Thanks for the help.

Answer 8

I also am having this problem with the release version of VS 2005.
I have multiple projects with usercontrols in each project.  The main project references and uses the usercontrols from the other projects.  When compiling, VisualStudio (devenv) retains a lock on the referenced assemblies bin folder's dll and will not copy the file from the obj folder to the bin folder.  The resultant error is:

Unable to copy file "obj\Debug\myUserControls.dll" to "bin\Debug\myUserControls.dll".  The process cannot access the file 'bin\Debug\myUserControls.dll' because it is being used by another process.

I ran FreeFile on the dll and find that the devenv process is the only process locking the file.  This is definitely a Bug.

Restarting Visual Studio fixes the problem till next time.

Answer 9

Yes, this is the right forum. We've seen a few reports of file locking issues, but they are very difficult to diagnose when we're not able to reproduce the issue locally and we don't have any resolved issues to draw on. If you're willing to send us your full solution I'll take a look at it and try to figure out what's causing the problem. If you can construct a subset of your solution or a solution created from generic projects that still exhibits the problem it would work too, but from my experience it's not usually easy to do that.

Please contact me at msbuild *at* microsoft.com if you'd like us to have a look - we'll figure out the best way to transfer the solution based on its zipped size.

thanks,

Lukasz

Answer 10

I am having the same issues, as discussed in the threads listed below.

One of the key characteristics to reproduce seems to be:

Create assembly containing C# custom controls. Reference the assembly from the Win app. Changing the custom control tends to cause the locking issue.

(Actually changing any dll in the hierarchy below the Win.exe seems to cause this issue.)

This issue is so reproducible, I can reproduce it just about at will on just about any build. Annoying - keep having to restart VS.

My applications were ported from VS2K3. Could this be a contributing factor? How many other applications were also ported?

Indexing service is blocked from the folders.

http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=71856&SiteID=1

http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=203142&SiteID=1

 

Answer 11

Brian,

Since you have specific repro steps that show this please log the bug against us using the MSDN Product Feedback Center. Be sure to include the specific repro steps and a sample project, if possible. This will get a bug directly in our bug database and we'll be able to investigate.

Neil

Answer 12

That sounds exactly like my problem down to a T except my custom controls are in the win app, yet you change pretty much anything that the win app relies on (sometimes even the win app itself) and I have to restart VS2K5

Answer 13

Hi Neil,

Looking in the bug database provides this matching defect:

Bug ID: FDBK30218 Problem Type: Bug Status: Closed Resolution: Not Reproduced Microsoft Status:   Reviewed Opened Date: 2005-06-18 05:05:57 Opened By: ramrex

Product/Technology: Visual Studio Version: Visual Studio 2005 Beta 2 Product Language: English Category: IDE General OS: Windows XP Professional OS Language: US English Submission Language: English

Could you have it re-opened and supply additional information?

How would you like me to proceed? Unfortunately my code is for production and I cannot release it to MS for analysis.

Thanks,

B.

Answer 14

Brian,

You should be able to re-open it yourself using the product feedback center site and then include additional repro details.

Neil

Answer 15

Hi Neil,

I can't re-open it. Best I could do was:

1. Select Can Validate

2. Vote high priority

3. Submit comment

Are there other actions you can perform?

Thanks,

B.

Answer 16

Hi guys,

I have been developing under the vs05 environment for past 5 months, but never once i got this problem.

but for the past 2 days the subsequent builds afetr the 1st fails saying

Unable to copy file "bin\release\cls.dll" to "bin\release\cls.dll". The process cannot access the file ...

(same one you all face)

have any one reported this to microsoft and got any replies???

please keep us posted.

thanks.

Answer 17

Hi AnnaSa,

You may want to post over in this thread. It is the same issue and is receiving a little MS attention.

B.

http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=220689&SiteID=1

 

Answer 18

Hi,

I am curious as to whether you have any resx files in your custom control. We've had a recent bug where we realized that resource generation was responsible for what you are seeing.

Can you edit the project file for your custom control, and add this line to the top of the project, and see if that causes the file locking issue to disappear?  This will be fixed in a later release - but we are interested in finding out if this workaround will fix the problem for you.

<Project DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">

<PropertyGroup>

                 <GenerateResourceNeverLockTypeAssemblies>true</GenerateResourceNeverLockTypeAssemblies>

             </PropertyGroup>

Let us know what you find.

thanks.

Faisal Mohamood | Program Manager | Visual Studio - MSBuild

Answer 19

Hi Faisal,

Would you like me to add it to the existing propery group, or create a new property group?

Thanks,

B.

Answer 20

Add it to an existing one that does not have any conditions, or create a new one - either will be fine.

Thanks.

Faisal Mohamood

Answer 21

Hi Faisal,

I no longer work on that project, but have forwarded the test to the team. I will wait for feedback and keep you up to date.

Prelim testing in my environment shows that the solution works if you add that node to ALL the proj files in the solution.

Thanks for your time,

B.

Answer 22

I am seeing the same type of problem wit ha medium size solution that I've recently created. I do have some post build events but they are very minor. These post build events are very simple. All they do it copy assemblies to a common ext directory. My application uses a pluggable architecture so the exectuble assemblies need these binaries but they do not reference them.

I guess my question/problem is two fold. Is there a better way to structure a solution like this. Maybe someone here has some input on a good way to structure an "adapter" architecture type project such as this. I am always grateful for ideas and suggestions.

Answer 23

FWIW - I have been seeing an identical problem. We have multiple (many dozens) of projects which are shared across multiple solutions. I have been seeing this problem recently when more than one solution is open. Typically the 'locking' involves one or two projects that are shared by these solutions.

I attempted the proposed fix - adding it to just the single project that contains a Custom Control. Preliminary testing indicates it may have solved the problem.

Hope this data point helps.

Answer 24

OK, well interestingly, the problem has gone away. I can't exactly remember how I did it. I think I just checked everything into SourceSafe, deleted my folders and then got everything out again.

It's gone. I know that's of absolutly no help what so ever and a month or so ago I was tearing my hair out but yeah. It's gone.

Answer 25

I tried what you said, but still getting the same error.
We just moved our project from 2003 to 2005. From then i can't build my project from second time.
Getting:
Error    57   
Unable to copy file "obj\Debug\XXXX.Controls.dll" to "bin\Debug\XXXX.Controls.dll".
The process cannot access the file 'bin\Debug\XXXX.Controls.dll' because it is being used by another process.

Answer 26

The tag:

<GenerateResourceNeverLockTypeAssemblies>true</GenerateResourceNeverLockTypeAssemblies>

does not solve this problem. It's a shame because the only workaround is to restart the IDE. When I restart the IDE, i have to then 'rebuild all' in order to get the forms to show in the designer. I'm losing about an hour a day to this.

I've also tried to close the handle using Process Explorer, as i used to use this to work around a similar bug in vs2003, but it's not effective for me.

Answer 27

see my solution here

https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=90699

Go up to project properties->compile and change the build output path to \bin or to bin\Debug (another directory) on the project which file is being locked. Then Rebuild project and all should be ok.

 

Answer 28

I've got the same problem. Project assembly (objects.dll) is locked by VS 2005 (release). I get error "cannot copy from obj\bin to bin\debug ..." even when solution is compiled. This assembly contains only classes and interfaces, used almost in all other projects. There are 24 projects in the solutions and approx 1100 files in all projects.

The most reliable method for me is to change Output path for locked project (as eugene_Athlas says). All dependent projects are rebuilded but it is the fastest way in my case to make VS compile solution.

Answer 29

Has there been any progress or solution to this problem?

I am now seeing this on our builds.  This is a solution file with 9 projects and ~2500 source files.  We upgraded to Visual Studio 2005 last month, from Visual Studio 2003, and all projects were imported from the Visual Studio 2003 projects.

I now see the same problem as reported above:

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

Stopping Visual Studio 2005 and restarting it fixes the problem for one build (the next build causes it to re-occur).  No other applications are being run.  It first occured when I modified an assembly to which xxx.dll depends.  No changes to xxx.dll were made when the problem was first observed.  All references to xxx.dll have the property: "Copy Local: True" set.

The DLL causing the problem contains no custom controls.  It consists of several components (with .resx files), and data set code.

Adding the <GenerateResourceNeverLockTypeAssemblies> change to the xxx project file does not correct the problem.

We are using Visual Studio 2005, verison 8.0.50727.42 (RTM.050757-4200), with .NET Framework version 2.0.50727.  The projects are C# assemblies, and a simple bootstrap C# launcher.  We use Visual Source Safe - version 6.0d (Build 9848) for source control.

Any advise or information on how to fix this would be appreciated.

Thanks.

Answer 30

I have a very similar issue, but its not VS2K5 (and VS2K3 when we were on that) that is holding the lock on my assemblies, its IIS (specifically W3svc). My project uses multiple custom controls and functionality in assemblies that are loaded at runtime using System.Reflection.Assembly.LoadFrom(...). As soon as this is invoked (the user loads a page that uses a control in question), ASP.NET loads the assembly, but never releases it. Even though my code disposes the instantiated objects, the assembly itself is NEVER released by ASP.NET (even when there are no longer any pages open in any browers) until you stop the W3 service. I've noticed though, that this doesn't happen to assemblies that are in the /bin folder of the web-application. There is some sort of caching going on. Is it not possible for VS to either put caching into place on the output (bin) folders of projects that are compiled. Or if this is prohibitive, then in the project properties, create an option for "Cache for web-deployment" or something similar. Because, seriously, restarting W3svc everytime I want to compile something is starting to become a serious pain. Either that, or get the ASP.NET team to play nicely with others, and release the assembly when it is no longer in use.

 

Raptyr

Answer 31

Chiming in; when will this be resolved? Why is the bug closed? None of the suggested solutions work for me. I'll soon make the switch to SharpDevelop for this project if nothing is done about it.

Answer 32

I'm having the same problems with my projects using VS2005. I see that there has been no recent responses to the previous posts but hopefully someone will read this and give us a solution.

Anyone know of a solution then as it is most annoying to keep having to exit and restart VS2005 everytime it occurs?

Answer 33

One of the reason i see for this probelm is when u add a reference to the project in the same solution. add reference to the project not to the dll generated after building it..like browsing to till debug folder and add the dll as reference. When u build the entire solution the project u added builds and generates the dll but it actually added as reference to another project.

I don't know whether this is the problem u r facing..if not excuse me for wrong hints.

-mahi

Answer 34

The solutions refer to other solutions, not to the DLL's generated by those solutions.  Adding references to the DLL would cause complications and more difficult deployment problems because we need to be able to easily build both debug versions and release versions of an entires solution.

Our solution has 8 projects, with dependancies organized as:

Project 1 depends on projects 2 and 8.
Project 2 depends on projects 3, 4, 5, 6, 7, and 8.
Project 3 depends on 4, 5, 6, 7, and 8.
Project 4 depends on 6 and 8.
Project 5 depends on 6, 7, and 8.
Project 6 depends on 7 and 8.
Project 7 depends on 8.
Project 8 stands alone.

If I remember correctly, 2, 3, 6, and 7, and possibly 4 and 8, were created on the original Visual Studio release (2000?).  1 and 5 were almost definitely added while we were using Visual Studio 2003, possibly 4 and 8 (I don't remember the exact timing for these two DLLs).

Not sure if it is important, but many projects also depend on some 3rd party DLLs (ActiveReports), some generated COM interop DLLs (MS Office), and various .NET assemblies.

In any case, this solution built correctly and successfully using Visual Studio 2003, though occassionally we would see a similar problem if a component or control was left in design mode during a build (I don't remember the precise details).  This specific problem is only seen with Visual Studio 2005, where if a source file in project 8 (and possibly project 7) is modified, project 6 fails to build with the error message indicated in this thread.

Answer 35

Every one in our development team (>50 developers) has had this problem for as long as I can remember (both studio 2003 & 2005). It is less frequent in 2005 than in 2003.

We use "Unlocker" in a post build event to work around it, it's ugly but it works most of the time.

I have reported on this for studio 2003 but nothing happens...
please, could you just let go of all file handles after a build!

Answer 36

best solution i figured out is to "restart the explorer.exe" from windows taskbar, and then compile & run. you dont even need to restart visual studio.

Answer 37

Hi,

This is one thing that has bothered me quite often from VS2003 to VS2005.I always found some strange ways of workaround and often it dissappeared and reappeared.

Recently working on VS2005 with multiple projects in a solutiion and some of the projects beng projects to the other projects, it appeared again.

Also I noticed that If I compile in debug mode error is thrown but if I compile in Release mode it gets compiled successfully.

All I did was create a new folder called Analysis2 and move all the existing projects to the new folder and rebuild a new solution and add all the projects to it one by one and work with the project.This is one work around.

The other workaround as mentioned already in the posts is change the Build OutPut Path from Bin\Debug to Bin folder and things work fine.

Stopping and starting the indexing service sometimes does help but it is not a guaranteed solution.

Thanks

Seshu

 

 

 

 

 

 

 

Answer 38

I got the same error message after adding this:

<hostingEnvironment shadowCopyBinAssemblies="false" />

to the <system.web> tag in web.config. Originally I put that because it was suggested as a workaround for the "Cannot create/shadow copy" issue.

http://www.connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=227522

(workaround: http://www.connect.microsoft.com/VisualStudio/feedback/Workaround.aspx?FeedbackID=227522)

As soon as I added this to web.config I was getting this error message. The first build works, but any subsequent ones fail. In the beginning I was excited because it really reduced the time after build until the page showed up in the browser (I mean, you can really feel it's faster!).

Anyway, for now my solution is to remove the workaround from web.config (which makes the error go away) and deal with the shadow copy issue (which is far less frequent). I just hope this may help somebody from the VS team figure this out; it really is a black spot on a otherwise good product.

 

Answer 39

We've had this problem with Studio 2005 from the outset:

error MSB3021: Unable to copy file "obj\Debug\XXX.dll" to "bin\Debug\XXX.dll". The process cannot access the file 'bin\Debug\XXX.dll' because it is being used by another process.

These suggested workarounds do not help (at least for us):

Installing SP1.
Disabling Visual Studio hosting.
Setting the <GenerateResourceNeverLockTypeAssemblies> project property.
Disabling the Windows Indexing Service, or virus scanners.
Cleaning the solution.
Restarting explorer.

Okay, I finally got tired of the try to build/get error/close and restart studio/reload solution/build again cycle, and played around with the problem some more.

So it appears to be related to particular solutions when they are set as the Startup Project.  I can work around the problem by setting another project as the Startup, then building and launching the debugger from the context menu for the project I'm building/debugging.

This should make it pretty clear that it's a Studio issue.  MS?

 

Answer 40

Can you provide a step by step procedure to achieve this ?

So far the only things that works from time to time is to change the output directory (that mean I keep the properties page of the project open and keep switching between 2 differents directory witch works 80% of the time. Lately one of the project in my solution developped the same problem and even changing the output directory doesn't work on this one. Got to shutdown visual studio and restart everytime...

I would like to know how to implement your "unlocker" solution.

This issue is really a waste of time.

Thanks for the help.

Mat

Answer 41

Any progress on a patch that would fix this bug ? It's a major issue. Having to restart visual studio between every build is such a waste of valuable time.

Thanks.

Mat

Answer 42

This problem seems to be pretty active and fairly wide-spread. I am no longer working on converted projects (from 2003) and for me, the problem seems to have disappeared.

Has anyone tried VS 2K5 SP1?

It concerns me that it doesn't concern anyone at Microsoft???

 

Answer 43

I'm running VS 2005 SP1 and this problem is not fixed. I have a small solution with 2 class libraries and 1 ajax-enabled web application project.  The main assembly from my web application project gets locked after any minor change to the code.

In my case, I used sysinternals process explorer to watch exactly when the assembly was locked. Devenv.exe actually locks the assembly files when I open an aspx file in the IDE (in either code or design view). I haven't compiled, haven't even editing anything. I simply open up an aspx file and devenv grabs on to that assembly like its life depends on it.

Answer 44

I have SP1 installed. It hasn't change anything. I have created a new solution with my 4 projects. Still no improvements. I get this error every other build. The only way to bypass this without restarting VS is to change the output path to undebug when it locks you change back to debug. At least that way you can compile without closing the solution. In some rare cases even this doesn't work. It seems no one from Microsoft is following this issue. Keep posting maybe that will get there attention.

Math

Answer 45

Thanks a lot for putting your solution in there. I removed the statement from web.config and now I can build it successfully.

 

Thanks

 

Answer 46

I think I figured out what is happening. Do you have an antivirus running ? I am using Avast antivirus and I've noticed that when I rebuild my solution I sometimes get the small tray icon from Avast popping up. After that my file is locked. I don't know if it's pertinent to any of you but when I program i stop Avast and I don't get this bug (at least not in the last 48 hours). Of this help you all.

Math

Answer 47

Has there been any further movement on this?

 

We're not using asp or webpages.  We're just doing window app development.  This problem wastes at least an hour a day for me and each of my co workers.  I can't imagine that it is any less for anyone else who uses this development environment and has to move projects from 2003 to 2005 or to use custom controls. 

 

So, what's the offical line on this - I can't find any open problems on it on the MS website.  I haven't found any solutions poking around on the web. 

 

Deb

Answer 48

I'm having the same issue. Small single-project applications, (1 VSTO 2003 Shared Addin in VS2005 and 1 VSTO non-addin in VS2005 on XPPro, SP2). I've tried many of the things listed here to no avail. Rebooting seems to be my only solution when this occurs. The problem is intermittent. Most people I work with have had the same problem, some more frequently than others.

No MSFT developers have seen this directly???

Answer 49

Same problem here, tried all the suggested workarounds, only thing that works every time is restarting VS. I'm quite angry at having paid MS such a large sum for an IDE that can only compile once before restarting. This is completely unacceptable.

Answer 50

My team at work is getting this error all the time. We've resorted to merely restarting Visual Studio (2005 Team edition) every time. This is ridiculous that this has been a reported problem for over a year now and there's still no permanent solution?!

Answer 51

I was getting so fed up with this damn problem that I finally went thru the pain of finding a solution for it. The sugesstion previosouly offered in this thread worked for me,

 

In the startup project only,

 

add (insert it before the existing entries):

<GenerateResourceNeverLockTypeAssemblies>true</GenerateResourceNeverLockTypeAssemblies>

 

to the first property group under :

<Project DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">

 

So far so good.

 

-Andy

Answer 52

We have the problem when building on the commandline, the build within VS2005 works fine.
The commandline builds 12 solutions consecutively  and the problem is caused by a project reference. This porject is part of the first solution we build, and is included as Project Reference in  an other solution. There the error occures, it seems that the file still locked from the first solution. Strangely this error did arise AFTER MONTH without a problem..

 When i added the prebuildevent posted befor into the project which was referenced, the whole thing works fine:
  <PreBuildEvent>if exist "$(TargetPath).locked" del "$(TargetPath).locked"
if exist "$(TargetPath)" if not exist "$(TargetPath).locked" move "$(TargetPath)" "$(TargetPath).locked"</PreBuildEvent>
    <PostBuildEvent>

Answer 53

My work around for this is to kill the "MyProject.vshost.exe" process right before I start the build/debug button. Sometimes I have to do it twice but it works without having to restart the IDE... but looks like the resolution above is the permanent ticket.

Answer 54

I haven't really found a fix per-say but instead of restarting visual studio you can just try to build the project again.  Usually it will go through the 2nd time.  This is what I have done up to this point.  It's faster than restarting VS.

Answer 55

 

My problem was linked to an XML file.  I right-clicked, selected properties, and changed Build Action to "none". Then the project compiled.

Answer 56

 

I found a workaround for this problem by using the build option instead of rebuild. If you get this error close your IDE and open the solution again. From that point don't use Rebuild instead use Build option. This way you will not get this error again.

 

Thanks,

Answer 57

It seems that most of us have a similar circumstance: we are developing .net application where the source code resides on a shared network drive and file locking is the major issue.  I have found a work around.. In solution explorer, go to the Startup project --> References --> select the name of the problem dll file.  Under properties, set Copy Local to False.

 

After this was done, I recieved a new error: Warning 1 Unable to delete file "bin\Debug\[ProblemDLL].dll". Access to the path 'S:\[SomeSharedDirectory\bin\Debug\[ProblemDLL].dll' is denied. [AppName]

 

Now go to Startup Project --> MyProject --> Compile

Change the Build Output Path from bin\Release\ to bin\[SomeOtherName]\

 

The solution should now run fine except for a warning in the error list window.  I'm not sure how the copy local = false affects how the solution is deployed, but it works fine for now.  If someone with a better understanding of this property could comment, I would appreciate it.

Thanks

Answer 58

I'm using vs 2008 beta and the problem exists even in this release
adding lines:

  <PropertyGroup>
    <GenerateResourceNeverLockTypeAssemblies>true</GenerateResourceNeverLockTypeAssemblies>
  </PropertyGroup>
to my project file doesn't repair anything, pretty annoying thing.

I hope that with a final release of vs 2008 this bug will be finally gone!

Answer 59

This may not be the same problem but I was getting Unable to copy file .

 

The error was:   Access to the path
'bin\Debug\CDInvoiceDropWatcher.pdb' is denied.

 

The problem is the dir Debug was included in the project. I use sourcesafe.

 

I excluded the Dir from the project and now I can build.

 

Hope this helps.

 

Jerry

Answer 60

Peter Zolja said:

I got the same error message after adding this:

<hostingEnvironment shadowCopyBinAssemblies="false" />

to the <system.web> tag in web.config. Originally I put that because it was suggested as a workaround for the "Cannot create/shadow copy" issue.

 

Same thing happened to me! Removing this line seems to have solved this. :-)

Answer 61

I was having similar problems with a new install of VS2005 SP1 on my new office PC.  Spent two days trying to find out why suddenly every time I'd compile my class library project in one instance of the IDE my other project that consumes the library would suddenly loose track of the class library assembly.

Turns out it was the virus scanner on the machine which has an On-Access scanner was holding the file lock that the IDE has on the file while it's being created.  After I added an exclusion rule to the virus scanner's on-access scan the problem went away.

So this is a solution that *seems* for the moment to be working flawlessly, YMMV.

James Colyer

Answer 62

I've come across this one many times, and have normally got around it by combinations of restarts, removal of .suo files or manually deleting the file VS couldn't copy/delete and not to say more than a few short anglo-saxon words.

However the last time this happened I removed the reference relating to the file it could not delete, then built the app, added the reference back in and rebuilt.
 
For instance if VS complains that it can't delete/copy file abc.dll when building fred.csproj, remove the reference to abc.dll, rebuild the solution (with errors) and then add the reference and rebuild.

It worked (!) ....   So far, so good............

Answer 63

I'm using VS 2008, still running into the same problem!!!
Have to close and restart VS and rebuild.

Repro:

I'm using mapping network folder inside a Virtual PC.

---

This is Zoe

Answer 64

I've been working on a very small project for testing for a little over a week.  Now I have to deal with this every time I compile.  It works once, then I have to leave Visual Studio completely and come back.  The only change to the program was implementing the MyApplication.Shutdown event to do a debug.print and including all the symbols for a few extra files to debug.  Extremely annoying.

Answer 65

Hi,

Still no update on this issue ? I'm experiencing the same annoying issue.

---

.NET C#

Answer 66

Hi,

we have been having this issue with our solution in VS2005 as well. We have multiple projects, both web apps and libraries in our solution. This works for us:

Clean Solution (Build > Clean Solution)
Change the start up project
Rebuild Solution

You can then repeat and change the start up project back to project you require.

Hope this helps..

Col

Answer 67

This is beyond annoying, beyond rediculous.  I have to restart Visual Studio at a minimum of 15 times a day.  this is NOT an exageration.  I've tried every "work around" or "hack" out there and nothing.  This seems to have been an issue all the way back to VS 2003!  Can we get a difinitive answer as to why this is happening?  I'm losing precious hours every day just rebooting VS.  I'm running VS 2008 SP1 building a WPF app.  This issue occurs on a regular basis when debugging.

---

Ben Abshire, Principal Software Engineer, Itron Inc.

Answer 68

This is beyond annoying, beyond rediculous.  I have to restart Visual Studio at a minimum of 15 times a day.  this is NOT an exageration.  I've tried every "work around" or "hack" out there and nothing.  This seems to have been an issue all the way back to VS 2003!  Can we get a difinitive answer as to why this is happening?  I'm losing precious hours every day just rebooting VS.  I'm running VS 2008 SP1 building a WPF app.  This issue occurs on a regular basis when debugging.

---

Ben Abshire, Principal Software Engineer, Itron Inc.

Dear Moderators, I know it's good for your performance reviews if you've "answered" a lot of questions, but could somebody please at least try to care about the problem?

Answer 69

I'm using Visual Studio 2010, or 10 as MSFT would have it, and in the Beta2 build this still isn't fixed and probably will still be around in VS 2025.

My solution came from Steve who suggested to change the build action for a xml file to "None", I have absolutely no idea why this worked, and the time I did it, it crashed Visual Studio, but now it loaded fine, and surprise, surprise no more errors. Also I think this problem has something to do with porting a solution from one visual studio to the next as this project worked fine for me on VS 2010 Beta1 until I switched to Beta2. Also I see that many of you are using solutions upgraded from one increment of VS to the next so my guess would be that something gets messed up in the migration process.

Not that it matters, MS doesn't seem to be taking this seriously.

Answer 70

Strike that the problem isn't fix, it came back after I restarted VS.

Answer 71

I'm using Visual Studio 2010, or 10 as MSFT would have it, and in the Beta2 build this still isn't fixed and probably will still be around in VS 2025.

My solution came from Steve who suggested to change the build action for a xml file to "None", .........

Not that it matters, MS doesn't seem to be taking this seriously.

Well disabling "Generate XML Documentation" truly works but the dark side is you no longer get support for XML Documentation which i use very often whenever i am writing a new function or sub i like to document it thoroughly. Its really a pain in the butt if you disable it. And im really sorry to hear it was not fixed in VS 2010. Seems as though microsoft is playing dumb on this one.

Answer 72

I have had the same issues as everyone and the Solution for me is always taking ownership of the bin on each Project within the Solution as Administrator.
Then clean/rebuild.

 I understand what you are doing with the assemblies but when you start modifying your config, maybe its time

to look at the real issue with your project, egh? I found this really came down to the correct permissions on my

folders. Additionally if you are working in Team System or VSS Getting latest w/ Specific usually resolves this.

Answer 73

im also seeing this in vs2010 RC

so sad that microsoft doesnt seem to care..

 

Answer 74

This is becoming ridiculous ... this is the third time that I am restarting my environment today. This tends to happen for me on large projects that contain a few xml files with a build action of embedded resource.

I have noticed that if I have an error, try to rebuild all, fix the error and rebuild all the files are locked.

A resolution for this would be much appreciated.

Answer 75

We manually cleared out all the files in the bin folders and then did a build and that solved our issue. A clean didn't help.

 

Answer 76

I encountered this problem for the first time this morning with Visual C# 2010 Express Beta 2 and spent some time tracking down the cause (at least in my case). It turns out that at some point Visual Studio went and added the debug executable of my project to its own references. The copy-to-local flag was also turned on so it was trying to copy the debug exe into the target folder while it was building it, hence the copy error. Removing the exe from References fixed the problem.

I've noticed that Visual Studio seems to get amnesia from time to time and think that various child controls are no longer part of the application, my guess is that it thinks these controls are part of an external package and then automatically adds that to it's references, not realizing it's the same application.

 

Answer 77

Hey I got the same error "cannot save ......." . I think the problem is with the exe file. We run the program using run option in VS and when we kill it, the exe just doesn't kill, it goes into background (you can check it in task manager> processes). And that's why it's showing "Already opened and cannot build".

My advise to them who are getting error is to open task manager and kill exe process (and build project after that , you will definitely be able to do that) and from the next time run the exe by only opening it from its original path (and not using the run functionality in VS).

Answer 78

I'm using VS2010, and have the same problem with the error 'Unable to copy file "obj\Debug\Library.dll" to "bin\Debug\Library.dll". The process cannot access the file 'bin\Debug\Library.dll' because it is being used by another process. '

It is frustrating, to say the least, that Microsoft does not do anything about this. Maybe a new thread, with a bit shorter list of comments, might evoke some new feedback from them.

My advise: Use the little tool Unlocker to delete the problematic file specified in the error message, and building the solution will work just fine.

 

Answer 79

hi to all,

i face all cases on that post, and finally i got the solution for my code, i was added the following tag in web.config

<hostingEnvironment shadowCopyBinAssemblies="false" />

when i comment this, all of my projects work fine,

hope this will help.

Answer 80

Till y'day, I was able to delete the obj folder and was able to build the VS 2005 and proceed, but now that solution also failed. Its a showstopper for me now.

 A and B are two projects and for both of them, the output folder is bin.

Unable to copy file "obj\Debug\A.dll" to "bin\A.dll". The process cannot access the file 'bin\FAAdminSite.dll' because it is being used by another process. 

Unable to copy file "obj\Debug\B" to "..\A\bin\B". The process cannot access the file '..\A\bin\B.dll' because it is being used by another process.

Answer 81

99% of the cases I have come across and helped people solve evolved around things that DO NOT INCLUDE Visual Studio. Unless you create a buggy application that cannot release its resources properly and kill itself, then you should look for things that may lock that dll, aside from Visual Studio. Here's a proven track you can follow to solve the issue (try a rebuild after each step to see what helps):

1. switch from debug to release (for the sake of changing the output folder) or change the build folder path to another location and observe whether or not the build goes through. if the build goes through, then it's not VS, its something else.

2. make sure you don't have any search utilities running that can lock newly created files. remember, when you do a build you create new files and most of these utilities are watching the file system for new file creations (in short, stop, shut down, get rid of: google desktop, microsoft live search etc, stop indexing / search services; whatever that you can think of that may lock the file).

   If after the second step, you can successfully build, then that means that the search indexing software was the culprit. either make sure that it does not index your project folders, or make sure it stays offline while you are building projects

3. shut down all anti-virus utilities (this is the biggest culprit). again, when you build, you create new files and all good anti-virus software are on the lookout for new file creations. and they block, lock and do all sorts of things to files. most of the time they release the file afterwards, but then again, sometimes they don't. so stop all "resident shield" type of things and try a rebuild

   If after the third step, you can successfully build, then make sure your anti-virus stays out of your project folders. or, just turn it off, do your rebuild, then turn it back on. you know the drill

Again, in my experience of a decade of building .Net apps, I have found that 99% of the time, it's one of these environmental issues that cause this fun behavior. Of course, programmatic, and VS caused issues persist, but these 3 steps should help you out in most cases.

Good luck

---

the art of peace begins with you

Answer 82

I found the solution was to delete the Solutions SUO file and restart devenv.

Answer 83

I'm using vs2010 and I've found as others have that it has something to do with a designer being opened. I can make changes to a user control all day, and if I don't have a designer open that hosts the control, I operate fine. Once I open a designer with the control, the error starts. Even if I close the designer, the error continues until I close visual studio. Strangely enough, this did not happen once in VS2008.

The only work around I've found is, when I receive the error, I go to the project build properties and set the output path to a new folder. This will allow me to continue for the time being. You must make the value unique each time you receive the error because, and this is the strange part, visual studio continues to hold the file open, even though you've changed the output folder and it compiles into the new folder you've specified. You can't even go to the file system and remove those folders while visual studio is open. I use "Debug1, Debug2, Debug3, etc" until I shut down visual studio, then I can delete the erroneous output folders.

Hope this helps others as this is very frustrating.

Answer 84

I got this error for the first time today and checked this forum. I've recently started using VS2010 and I never had this error on VS2005 or VS2003. I tried the solution above, and in fact, I am able to rebuild several times if I don't have a custom control open in design mode. I haven't tried the other solutions.

Answer 85

Def something to do with opening forms in the designer for me. I find that the pre-build event command line options $(TargetPath).locked, etc works but then stops working after a while so I finally got around to writing a simple Console App which replaces this. I called it VSUnlocker.exe and made it take the TargetPath as an argument. I added the line "some other location\VSUnlocker.exe" "$(TargetPath)" to the Pre-build event command line and it seems to be doing to the job nicely.

Basically it cleans up all locked files in the output folder, copying your application to an incremented .locked file name each time it comes across a previous .locked file that's cant be deleted. It's a band-aid but its better than the alternative and it works!

 

using System;

using System.Collections.Generic;

using System.Linq;

using System.Text;

using System.Diagnostics;

using System.IO;

 

namespace VSUnlocker

{

    class Program

    {

        static void Main(string[] args)

        {

            if (args.Count() == 0) return;

 

            int index = 1;

 

            string path = args[0];

            string locked = "";

 

            DirectoryInfo x= Directory.GetParent(path);

            string exe = Path.GetFileName(path);

 

            //Clean up any locked files that are now unlocked

            foreach (FileInfo file in x.GetFiles().Where(X => X.Name.StartsWith(exe + ".locked")))

            {

                try

                {

                    File.Delete(file.FullName);

                }

                catch { }

            }

 

            while (index < 1000) //Better than no break point

            {

                locked = path + ".locked" + index.ToString();

                if (File.Exists(locked))

                {

                    try

                    {

                        File.Delete(locked);

                        break;

                    }

                    catch

                    {

                        index++;

                    }

                }

                else

                {

                    break;

                }

            }

 

            if (!File.Exists(locked) && File.Exists(path))

            {

                File.Move(path, locked);

            }

        }

    }

}

 

Answer 86

Oh and as an unexpected bonus, it allows me to build my apps even if I am already running the same app outside the debugger

Answer 87

Hi all,

not sure if this will help anyone, but I will still post it just in case. I had a similar problem (i.e. error message), but it happened that it was not related to the bug in VS 2010. The problem was related to the fact that I had one of the bin\Release folders checked in under TFS. 

The problem was caused by the fact that one of the projects has a custom action that copies the project's output into the other project's Release folder. Since the folder was under TFS then the action was failing. 

 

The reason I post it in here is because the error message was the same you are facing and it is possible that some folks are as inattentive as I am.

Obviously, this was fixed by removing bin\Release folder from TFS.

---

Kotena

Answer 88

Quick solution to this, change where it says debug to release. Worked for me.

*Note* There is a drop down near the debug (play), pause and stop button that is set to debug as default change that to release.

---

Ryan Smith

Answer 89

This problem seems to occur for me in VS2010 when I change the background colour of the form.

---

Ryan Smith

Answer 90

I had this same problem.

Error 1 Unable to copy file "obj\Debug\DMS.Apt.xml" to "bin\Debug\DMS.Apt.xml". Access to the path 'obj\Debug\DMS.Apt.xml' is denied. C:\WINDOWS\Microsoft.NET\Framework\v3.5\Microsoft.Common.targets 2703 9 DMS.Apt

My problem was a circular reference in my project file.   The offending lines of code, in the vbproj file, looked like this:  I removed them.

    <Reference Include="DMS.Apt, Version=2011.4.1003.55, Culture=neutral, processorArchitecture=MSIL">
      <SpecificVersion>False</SpecificVersion>
      <HintPath>obj\Debug\DMS.Apt.dll</HintPath>
    </Reference>

Someone had referenced the output dll from the building project.

Answer 91

Had this problem for a couple of days it just started out of the blue. Every time i changed code and tried to debug i got the error. I tried every solution on the net and nothing worked so then reinstalled VS2010 but still had the problem. This got me to thinking that it wasn't a VS2010 problem but a directory permissions problem. It was, for me anyway. I did not have full permissions on the Projects directory.

Here's what worked for me on Win 7. ( You probably have to have Administrator rights to do any of this.)

Right click the Projects folder e.g. "My Documents\Visual Studio 2010\Projects" click "Properties" then the "Security" tab. Click the "Edit" button.
If your logged on name is not in the "Group or user names" list, click "Add", "Advanced", "Find Now" and click on your **username from the search results, click "OK" and "OK" again. Now your logged on username will be in the "Group or user names" list. Click the Allow Full Control checkbox and Apply.

**There will be a lot of Users and Groups when you perform a search, your looking for your username, the name you see when you click on User Accounts in the Control Panel, the account you are logged on with.

That worked for me, i hope it can help someone else.

Answer 92

 I changed configuration property  from solution property page by creating a new configuartion by copying debug to debug1.

Smithin K Vijayan
MCPD

Answer 93

Hi All,

Please Check application configuration settings.

VS2010->Build->Configuration Manager

and also Check all projects are in Debug mode or different.

and aslo check the Build check box is checked or not correctly for all projects.

I hope your problem will get reslove.

Answer 94

This problem has just occured for us too: We have two large solutions (sharing projects). Everything has been fine for 4+ years on VS2008. We've just converted to VS2012 and bang! Same problem. Nothing else has been changed. Switching the solution between Debug and Release works ok but it's a pain to remember doing this each time.

Answer 95

I continue the work by forcing the cancellation of the file.
I use the unlocker program in the public domain:
http://www.filehippo.com/it/download_unlocker/

To configure do so:
In the "Solution Explorer", right-click a dll (any)
Then do a "Open with" and then I select the program unlocker
Then "Set as default".

In case of problems:
- Double click on dll (in solution explorer)
- Choose the Delete option
- Button "Unlock" (does not end the process!)

However, it remains a big nuisance

Answer 96

I found that if I use a '*' in the assembly number to get auto-incrementing builds, then I have this problem. If I don't use a '*', the the problem goes away.