Visual Studio .NET Bug

  • Thread starter Thread starter Reilly
  • Start date Start date
R

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?
 
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.
 
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/defaul...port/kb/articles/q313/5/12.ASP&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
 
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.
Click to expand...

Yep. I'm using project references.

Thanks for the help.

Trev.
 
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
 
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.
 
Back
Top