Visual Studio .NET Bug

[Reilly]

We are experiencing a debilitating VS.NET bug, in both 2002 and 2003.
We have solution with about 20 projects. 90% of the time, when we
rebuild, we get one or more errors saying "Cannot copy assembly 'xxx'
to file 'yyy'. The process cannot access the file because it is being
used by another process."

Sometimes, waiting 30 seconds makes this go away. Sometimes, we have
to exit and restart VS.NET. Sometimes, we have to reboot Win2k.

I have seen this bug posted MANY times in Google, and on GotDotNet.
No uSoft engineer has responded.

What gives, Microsoft? Does anyone know how to fix this?

[Eric Cadwell]

Check your references. Have you set Copy Local to True?

HTH;
Eric Cadwell
http://www.origincontrols.com

[Codemonkey]

> Have you set Copy Local to True?

I experience this problem intermittently. I have local copy set to true on
the references. Should this be the case?

I have all my projects set to build their executables to a single directory
as they form part of the same application.

Thanks for the help,

Trev.

"Eric Cadwell" <ec******@ns.insight.com> wrote in message
news:e2***************@TK2MSFTNGP11.phx.gbl...

Check your references. Have you set Copy Local to True?

HTH;
Eric Cadwell
http://www.origincontrols.com

[Eric Cadwell]

If your building a large solution with redundant references there's a chance
that the file could still be in use when it tries to copy it in again. This
results in the error.

Microsoft is recommending that you build to individual output directories.
http://support.microsoft.com/default...NoWebContent=1

You could then set up a script to copy them to a common folder once they are
built.

Also note that they recommend using project references.

HTH;
Eric Cadwell
http://www.origincontrols.com

[JackJian]

use the project reference would resolve the problem.

-----Original Message-----
If your building a large solution with redundant references there's a chancethat the file could still be in use when it tries to copy it in again. Thisresults in the error.

Microsoft is recommending that you build to individual output directories.http://support.microsoft.com/default.aspx? scid=http://support.microsoft.com:80/support/kb/articles/q3
13/5/12.ASP&NoWebContent=1
You could then set up a script to copy them to a common folder once they arebuilt.

Also note that they recommend using project references.

HTH;
Eric Cadwell
http://www.origincontrols.com
.

[Codemonkey]

> Microsoft is recommending that you build to individual output directories.

99% of the time it works ok. Closing and reopening the IDE isn't that much
of a pain (yet!)

Also note that they recommend using project references.
Yep. I'm using project references.

Thanks for the help.

Trev.
"Eric Cadwell" <ec******@ns.insight.com> wrote in message
news:uE**************@TK2MSFTNGP09.phx.gbl... If your building a large solution with redundant references there's a chance that the file could still be in use when it tries to copy it in again. This results in the error.

Microsoft is recommending that you build to individual output directories.
http://support.microsoft.com/default...NoWebContent=1
You could then set up a script to copy them to a common folder once they are built.

Also note that they recommend using project references.

HTH;
Eric Cadwell
http://www.origincontrols.com

[Jason Dorie]

I have this problem frequently on my project as well. I believe part of the
problem is that I'm creating controls and using them on forms (or other
controls) in the same project. I believe VisualStudio isn't unloading the
used controls from the designer once they're loaded, meaning that I have to
shut it down frequently. I sure hope they fix it at some point - I kinda
miss "real" dll's that unloaded properly.

Jason Dorie

"Codemonkey" <hu*********@hotmail.com> wrote in message
news:uk*************@TK2MSFTNGP10.phx.gbl...

Microsoft is recommending that you build to individual output directories.

99% of the time it works ok. Closing and reopening the IDE isn't that much
of a pain (yet!)

Also note that they recommend using project references.

Yep. I'm using project references.

Thanks for the help.

Trev.
"Eric Cadwell" <ec******@ns.insight.com> wrote in message
news:uE**************@TK2MSFTNGP09.phx.gbl...

If your building a large solution with redundant references there's a

chance

that the file could still be in use when it tries to copy it in again.

This

results in the error.

Microsoft is recommending that you build to individual output

directories.

http://support.microsoft.com/default...NoWebContent=1

You could then set up a script to copy them to a common folder once they

are

built.

Also note that they recommend using project references.

HTH;
Eric Cadwell
http://www.origincontrols.com

[Reilly]

Thanks to all responses.

We have been using project references since the beginning. We have
also been building to separate output directories.

We **had** "Copy Local" set to True, and changed it to False. Same
problems.

If I run "ProcessExplorer", another wonderful tool from
sysinternals.com, I can determine that devenv.exe has a handle to the
file that devenv.exe complains it can't copy to because "another"
process has the file locked.

The problem is the same in 2003.

We have a Solution with about 9 C# class library assemblies, 1 managed
C++ class library assembly, and 2 executables. Ever since we added
the managed C++ project, we've had these problems. But they were
always confined to the MC++ project DLL, and building 2 or more times
would succeed. Now, the locked DLL has migrated to include most all
of the C# assemblies, also.

I saw something (somewhere) indicating that Intellisense might have
the DLL open, and might not be letting it go.

Thanks for any more suggestions.

john.