I have been busy the last few days writing lots of code for business and data components. I came across an interesting “bug” in VS.NET. In my unmanaged days, I would compile all binary files to a central location in order to quickly register and/or deploy them into an install application. Carrying over that habit, I set up my VS.NET projects/solution to compile to one folder as well (i.e. Dev\Bin\Debug and Dev\Bin\Release, accordingly). But, late last night, I started to get this message:
Could not copy temporary files to the output directory.
The file 'assembly name' cannot be copied to the run directory. The process cannot access the file because it is being used by another process.
It turns out there is a bug in VS.NET: BUG: "Could Not Copy Temporary Files to the Output Directory" Error Message When You Build a Solution That Contains Multiple Projects (Q313512). Apparently, when an assembly gets over 64 KB in size, the IntelliSense engine of a project will lock a referenced assembly. The IntelliSense engine locks only those referenced assemblies that are larger than 64 KB. In this case, as I was seeing while debugging which assemblies the VS.NET process was holding, I did find my assembly being “locked“!
Mark Michaeliswrote about this last October and had some very helpful tips:
If you create a solution that compiles multiple projects to the same folder and the compile is larger than 64 KB you are bound to encounter and error such as "Could Not Copy Temporary Files to the Output Directory." To avoid this try the following steps:
- Set the Copy Local property of the project to True
- Leave the output to the VS.NET default location, ..bindebug for example.
- Setup references to point to the common output location, ..bin for example. Obviously this requires at least one compile.
- Add a post build step to copy the DLLs to the common location:
copy $(TargetDir)$(TargetName)*.* r:bin(Thanks to John Pritt for this info.)
