File locking problem in VS2003 / cannot copy assembly to output folder

Sorry for offtopic, but a few days ago i read a post here from Matthew Mastracci.

He mentioned his problem with the file locking bug in Visual Studio. This is a very annoying bug and i read many post about it in the past.

If you have big solutions, assemblys > 64k and vs shows this error:

*Cannot copy assembly to file \bin\Debug\Release\]]>.dll. The process cannot access the file because it is being used by another process. *


You should take a look here

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

This is a HotFix for Visual Studio that solves the problem


Carsten Jendro

4 comments
Comment actions Permalink

Hello Carsten,

we (as almost all others VS 2003 users) were also struggling with this issue,

and for a long time we were building every project from the ReSharper solution
into a separate directory
which was very annoying. Besides necessity of post-build steps (copying output
into a
single directory), that also had a drawback of slowing down the build process,
as VS needed
to copy all the referenced assemblies into each project output directory.

But now for already several months we've been using our
custom build system instead of VS BuildSolution command, and quite happy
with it.
Anyway, I think some users find the information you posted useful.

Regards,
Dmitry Shaporenkov
JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"

Sorry for offtopic, but a few days ago i read a post here from Matthew
Mastracci.

He mentioned his problem with the file locking bug in Visual Studio.
This is a very annoying bug and i read many post about it in the past.

If you have big solutions, assemblys > 64k and vs shows this error:

*Cannot copy assembly <Referenced Assembly> to file <Current Project
Output Folder>\bin\Debug\Release\<Referenced Assembly>.dll. The
process cannot access the file because it is being used by another
process. *

You should take a look here

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

This is a HotFix for Visual Studio that solves the problem

Carsten Jendro



0
Comment actions Permalink

Your Build tool is very nice :)

Unfortunately the "use own build tool" function loads informations from project files only once when solution is loaded don't detect changes here witout reopen the sln until now.

It is very clear and nice to use. Is this only included to test it for your own IDE or will it included in r# 2.0 final?

0
Comment actions Permalink

Hello Carsten,

hmm, I didn't think you've already discovered it. It really doesn't respond
gracefully to changes to projects in VS, we've not invested much effort to
it yet, and I'm not sure if it is possible to get notified e.g. of project
properties change in VS. So, as you see, the tool is far from being of a
production
quality. As for plans to include it into the ReSharper 2.0 add-in as an
end-user functionality, I'm not aware of such plans. Rather, it is intended
for
internal use only (as you undoubtedly noticed ;)).


Regards,
Dmitry Shaporenkov
JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"

Your Build tool is very nice :)

Unfortunately the "use own build tool" function loads informations
from project files only once when solution is loaded don't detect
changes here witout reopen the sln until now.

It is very clear and nice to use. Is this only included to test it for
your own IDE or will it included in r# 2.0 final?



0
Comment actions Permalink

Carsten,

Your Build tool is very nice :)
Unfortunately the "use own build tool" function loads informations from
project files only once when solution is loaded don't detect changes here
witout reopen the sln until now.
It is very clear and nice to use. Is this only included to test it for
your own IDE or will it included in r# 2.0 final?


Thanks for appreciation :)
Frankly speaking, it was developed for internal use just to get rid of
enormouse rebuild, problems while building all the project to the same
destination folder etc... I think, it's possible to open it for end-user,
but we have to discuss it.

Concerning detecting changes, there are a number of problems with
notifications from VS, but in fact, it's possible to cope without them, but
it will require some efforts, and right now it's not our primary goal.
--
Sergey V. Coox
JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"


0

Please sign in to leave a comment.