In a large C# solution, I have numerous projects and some COM wrapped .net controls.
After running the solution, a rebuild might fail with DLL cannot be copied to \bin locked by another process. It was not happening everytime so I thought may one of my components were not getting disposed correctly. The frequency of occurrence jump 10x after I moved to Windows 7 64bit and VS 2010. A GIS map control assembly always failed to build after it was run. Again, first this I thought was my implementation must incorrect. After some refactoring,I still have the problem, then I found this question on stackoverflow.
The workaround eliminated the issue for me.
It would be easy to blame VS 2010 or Windows 7 but given the complexity of the two products, little oddities are par for the course. Just glad for Stackoverflow!
Visual Studio build fails: unable to copy exe-file from obj\debug to bin\debug
Seems it is caused by using default assembly version numbers.
This same problem was discussed on Stack Overflow in this question: http://stackoverflow.com/q/2895898/310001
The following answer was proven to be one possible workaround:
http://stackoverflow.com/questions/2895898/visual-studio-build-fails-unable-to-copy-exe-file-from-obj-debug-to-bin-debug/2994502#2994502
I have verified both the bug and the above mentioned workaround in the attached project. In short, what to do to avoid this error is:
1. Open AssemblyInfo.cs in the WindowsService1 project
2. Change the line [assembly: AssemblyVersion("1.0.*")] to [assembly: AssemblyVersion("1.0.0")]
3. Save All solution files
4. Clean solution
5. Using a file browser, go into WindowsService1\bin\Debug\ and rename the locked file Solution6.Module.dll (e.g. to Solution6.Module1.dll - you must use rename, because you won't be allowed to delete it)
6. Go back into Visual Studio
7. Rebuild Solution twice
8. If the error still happens, go to step 4 and repeat again (I had to repeat once - it makes no sense, and I have no idea why, but it works)
When you get this far, everything should now be OK. You can rebuild as often you need to without any problems. Yes, you'll have to take care of incrementing AssemblyVersion manually, but it is a tiny tiny price to pay compared to many of the other "hacks" out there to work around this.
So in short: avoid using default Revision/Build numbers in AssemblyVersion!
The following answer was proven to be one possible workaround:
http://stackoverflow.com/questions/2895898/visual-studio-build-fails-unable-to-copy-exe-file-from-obj-debug-to-bin-debug/2994502#2994502
I have verified both the bug and the above mentioned workaround in the attached project. In short, what to do to avoid this error is:
1. Open AssemblyInfo.cs in the WindowsService1 project
2. Change the line [assembly: AssemblyVersion("1.0.*")] to [assembly: AssemblyVersion("1.0.0")]
3. Save All solution files
4. Clean solution
5. Using a file browser, go into WindowsService1\bin\Debug\ and rename the locked file Solution6.Module.dll (e.g. to Solution6.Module1.dll - you must use rename, because you won't be allowed to delete it)
6. Go back into Visual Studio
7. Rebuild Solution twice
8. If the error still happens, go to step 4 and repeat again (I had to repeat once - it makes no sense, and I have no idea why, but it works)
When you get this far, everything should now be OK. You can rebuild as often you need to without any problems. Yes, you'll have to take care of incrementing AssemblyVersion manually, but it is a tiny tiny price to pay compared to many of the other "hacks" out there to work around this.
So in short: avoid using default Revision/Build numbers in AssemblyVersion!
Source:VSIP
No comments:
Post a Comment