HELP! Visual Studio locks assemblies for ASP.NET project.

[WALDO]

I am working in an environment with 4 developers. 2 groups of 2 people
working on the same server on the same web project with no version control
management on the web server.

Programmers A & B servername/project1
Programmers C & D servername/project2

All programmers have solutions that have their respective web projects,
accessed over file share. Programmers A & B so far are fine. Programmers C &
D have a problem.

We have about a half dozen Component Libraries developed for use with the 2
web projects, but NOT stored in the GAC. Each reference to these component
libraries in the project is set to Copy Local = True.

When Programmer C opens his solution, it seems Visual Studio pushes the
local copies of the assemblies out to the webserver via the file share, but
keeps 2 or 3 of them opened and locked on the webserver.

When Programmer D opens her solution, while Programmer C still has his
instance of Visual Studio open, Visual Studio tries to do the same thing,
only since they are locked by programmer C they fail to be overwritten. And
the following error is produced.

Cannot copy assembly 'AssemblyName' to file
'\\servername\wwwroot$\Project2\bin\AssemblyName'. The process cannot
access the file because it is being used by another process.

As a result Programmer D's instance of Visual Studio does not load the
assemblies into IntelliSense. Her visual studio doesn't recognize any of the
same references that Programmer C's does. It prevents her from compiling and
various other things.


I have tried resetting IIS, removing Indexing from the Temporary ASP.NET
Files folders on both Programmer C & D's machines as well as the webserver,
using TaskManager to kill the aspnet_wp.exe process on all three machines,
deleting the VSWebCache for both programmers' machines. I have tried running
aspnet_regiis -i. I have tried recalculating the web.

The only workarounds I've figured out are to either have Programmer C close
Visual Studio, which releases the locks, then have Programmer D try to
Build, which then HER VS locks the assemblies and now Programmer C can't
build,

or

Whoever can't build because the other one has the locks, change the Copy
Local property of that reference to False for every reference to an assembly
that is locked just prior to Building, then change them back to True after
building, in which case IntelliSense still fails to load because when
setting them to True, it tries to push the assemblies back out to the
webserver and fails, thus repeating the cycle of hatred.

Either is unacceptable.

I recall reading from Microsoft that assemblies of 64K with Copy Local set
to False have this happen. Only one of the 6 assemblies is over 64K and all
are set to True. I also recall the virtual directories that have a trailing
backslash (\), or having another web project configured beneath a virtual
directory have this happen. Negative on both counts. I read that Visual
Studio might still keep something open because the assembly didn't close a
stream or a file, or visual studio needs to keep some piece of that assembly
in memory. I went through my code. 2 of the assemblies did any kind of I/O,
but not file I/O. These 2 are ones that lock. They read
ManifestResourceStreams from their own assemblies. I made sure that they
closed their streams, but I cant imagine that Visual Studio keeps them open
because only 1 of the 2 reads the ManifestResourceStream at design time. The
locks are instant, as soon as Programmer C opens the project, before any of
these calls are even made. I have also read that it is IntelliSense that is
locking these files, but when I heard that, it was only for the ones over
64K, which is only one of them.




Can ANYBODY tell me how to stop this madness?

Any and all help is greatly appreciated.

[hellswraith]

I am working in an environment with 4 developers. 2 groups of 2 people working on the same server on the same web project with no version control management on the web server.

That is your problem. Use VSS, it will simplify your lives after you learn to interact with it.

[area91]

If its over 64k and has intellisense on it will fail to compile...the message it gives you is wrong..has to do with a bug deep within vs.net..or at least that is what i was told