"could not write to output file" problem

[Daniel Billingsley]

Today I went to compile a solution I've been working on for months. I've
been off most of the last few months, so there's been a gap in the work, but
I did compile it a few times earlier this week.

Today I get a message:
Could not write to output file
'D:\DevelopmentProjects\Enterprise\CustomUtilities\obj\Debug\CustomUtilities
..dll' -- 'The process cannot access the file because it is being used by
another process. '

I found the KB article 313512
http://support.microsoft.com/default.aspx?scid=kb;en-us;313512 but it
doesn't seem to apply. I do have one assembly over 64k, but not the one in
the error message. Furthermore, the output paths and Local Copy settings
check out.

I thought I would try just deleting the file manually and recompiling.
Explorer says it can't delete the file. If I exit VS then I can delete the
file. Going back into VS I get a message that it can't find an assembly,
but it compiles ok. But only the first time, after that it's back to that
error message.

Any ideas what is keeping this file locked and how to fix it?

 

[Marina]

If you have 2 version of VS.NET open, where one project is refernecing
another, this can happen. Also, if you have a process manually load up an
assembly, it will get a lock on it.

Would be so useful if that damned message actually gave the name of the
process that has the lock...

 

[Daniel Billingsley]

No, only one instance open and no manual loading of assemblies. I rebooted
the machine to make sure there was some phantom process locking it and it
still did the same thing.

 

[Guest]

Daniel,

Mihaly,

I've had this problem, too, on more than one solution I've built. What
usually works is to remove references of the offending project from the other
projects that rely upon in, build the problem project, and then re-add the
references back to the ones that need it. This normally works, but if it
doesn't, I close down Visual Studio, and proceed to delete the /obj and /bin
files for all of my projects, restart Visual Studio and go on my merry way.

The first version of Visual Studio .NET had this problem, and I had hoped
that Microsoft had fixed it with the 2003 release, but it appears to not be a
significant enough problem for them. I only hope it gets corrected in
Whidbey.

-&&