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

Problem building
tessy
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.
adi151478
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
dush1
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.
Torsten K.
Hi Neil,
Looking in the bug database provides this matching defect:
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.
Kirill Tropin
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!
ming_68
Brian,
You should be able to re-open it yourself using the product feedback center site and then include additional repro details.
Neil
ieddy
Sayed Ibrahim Hashimi
www.sedodream.com
Dan Dittenhafer
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
Gerlop
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.
somebodyelse
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!
Stanislav Baranov
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
Rich.Wenger
Beel
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.
JackStri
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