IDE Locking Dependant files

[Paul Cheetham]

Hi,

I have a solution in VS.Net 2003 containing 2 projects - the main exe
project and a dll project.
The exe is dependant on the dll, and this is specified in the project
options, and the build order is correct - dll first then exe.

However, when I try to build the solution the build fails with the
message - "The file 'EfacsDataAccess.dll' cannot be copied to the run
directory. The process cannot access the file because it is being used
by another process."

The other process in question is the Visual Studio IDE!!!

This appears to be a major bug in the IDE, as it shouldn't really need
to have this file locked, and if it does it should release it before
trying to build it!

Has anyone else seen this, and has anyone got a solution that doesn't
involve closing the IDE?

Thanks.

Paul

 

[Guest]

Yes, We've had the same issue.. and it's a major pain in the butt. The best
way to handle that I've found it is to not include the dll project in the
main project's solution, but have it in another solution and have it already
built.

A small amount of good news is that vs 2005 doesn't have the issue.. but of
course you'll have to upgrade everything including the .net framework and
Windows installer (to 3.0). Dev studio 8 does make the managed / unmanaged
smoother (no vcclrit.h hoops).

Good luck. Maybe someone else will know of a better workaround.

 

[Paul Cheetham]

Thanks.

Apparently this is a well known issue, and affects all versions of
VS.Net 2002 / 2003. After a bit of searching I found complaints about
this all over the place.

Microsoft recognise it as a confirmed bug, and fixed it in October 2004,
but the patch is only available on request!

Check out these:

http://support.microsoft.com/default.aspx?scid=kb;en-us;313512
http://support.microsoft.com/default.aspx?scid=kb;en-us;887818


This patch should be released as a public download, as it is a major flaw.


Paul

 

[Guest]

Paul,

Just had the same problem myself, called Microsoft and received the patch.
It seems to have solved the problem just fine. If you call, just ask for the
fix for the KB Article 887818 that you mention.

-Rob