Hi,
We have just started getting the following error during compiles of our
forms-based application. We are developing in VS2008, VB.Net, with Team
Foundation Server-based source control.
Full error message is:
"Unable to copy file "obj\Debug\OurProjectName.xml" to
"bin\Debug\OurProjectName.xml". Access to the path
'obj\Debug\OurProjectName.xml' is denied."
This error has just started happening in our project in the last couple
days. It is intermitant and affecting all developers in our team. The only
way to get around it that we know of is to shut down/restart VS2008. It
will be fine for a few hours and then out of the blue start happening again.
Has anyone out there had a similar experience and found a solution?
Thanks
Bob Altman - 15 Mar 2008 01:16 GMT
FWIW, I've seen this same problem. I just took a quick look at the Microsoft
Connect website (the official place to provide product feedback -
http://connect.microsoft.com/VisualStudio) and I didn't see this exact problem.
That doesn't mean it hasn't been reported. More than likely my search criteria
didn't pick it up. Can someone else confirm whether or not this bug has been
reported?
Bob
CGatto - 18 Mar 2008 18:55 GMT
> FWIW, I've seen this same problem. I just took a quick look at the
> Microsoft Connect website (the official place to provide product
[quoted text clipped - 4 lines]
>
> Bob
Just as an update: I've downloaded a utility called ProcessExplorer that
allows me to find out which process has the file locked. Once that is
located I am able to delete the handle. Once the handle is deleted I can
recompile the app successfull. This leaves everything working fine until i
have to restart VS2008. Soon after that the error will happen again.
CGatto - 27 Mar 2008 14:17 GMT
> Hi,
>
[quoted text clipped - 16 lines]
>
> Thanks
Just an update on the issue for anyone who comes across the same thing. We
seem to have eliminated the problem but in a round-about way that we don't
quite understand. It seems as though our application had several unused
references in place which we removed (via Project Properties > References >
Unused References > Remove). One of those references was to a dll called
OurProjectName.dll located in the bin folder of the project. Why it was
there we do not know and no one can recall adding it in. Since it has been
removed the error has not occured again.