Visual Studio locks assemblies for ASP.NET project.

[Rob Mayo]

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,

 

[Joao S Cardoso [MVP]]

I know this will not help mutch but I believe that the best aproach on
webdevelopment is by far have the projects locally on a local IIS.

I know that this is not what what you are looking for, but since you dont even
have a source control system.... all developpers in one server will bring you
problems other than the ones you currently have.

In my opinion this is what you should do:

1 - The common libraries should be managed only by one developper (the person
responsible for buiding it) and distributed to the workstations for use by
others.

2 - Each developper installs IIS locally and works on the project locally.

3 - When a developper finishes development and testing the module he/she has
been working on then copies the file to the common folder on the server.

4 - When a developer needs to have the latest source code, its as simple as
copying the public folder with all file to the local project

3 and 4 can be replaced by using Visual Source Safe, but the first 2 remains the
same.

Hope this helps.

Regards

Joao Cardoso (MVP dotNET)
=======================================================
[LusoCoders]- http://groups.yahoo.com/group/lusocoders/
[PontoNetPT]- http://www.programando.net/regras.aspx
(e-mail address removed)-s.p-a.m - www.acinet.pt
=======================================================

 

[Rob Mayo]

OK, so talk to me alittle about using SourceSafe with web projects. We DO
have SourceSafe6.0c managing checkin and checkout of our Component
Libraries, so when one of us makes a change, the others have to get the
latest copy from SS. We have been wary of using it to manage our web
projects because of how poorly source code control interation worked with
InterDev 6.

We have done a little superficial research and we see that there are
basically 3 models for working with SS on web projects with VS.NET;
Isolated, which is the way you suggested, Semi-Isolated, where developers
work on different web applications on the same server, and Non Isolated,
which is what we're current;y doing, only not with SourceSafe, hence death.

In the way you suggest, how does SS handle concurrency between pages.
Granted if I have one checked out, no one else can edit it, but what if I
need to compile and I'm calling a method on a page/class that someone else
is working on. How does it fare with making sure that what one developer
does doesn't adversely affect another.

If you have completed a portion of a page and you want to see the results,
where do you point IE; to your localhost or the webserver? When does it push
pages out to the server; at check-in?

 

[Joao S Cardoso [MVP]]

Hi Rob...

I dont have a lot of experience from using VSS yet, but I'll try to help the
best I can. Perhaps others can complement my sugestions with more info.

OK, so talk to me alittle about using SourceSafe with web projects. We DO
have SourceSafe6.0c managing checkin and checkout of our Component
Libraries, so when one of us makes a change, the others have to get the
latest copy from SS. We have been wary of using it to manage our web
projects because of how poorly source code control interation worked with
InterDev 6.

I did had the a lot of problems with VSS first versions. It was quite buggy and
once I actually lost some code on the server and because of that I stopped using
it. Then version 6 came along and a lot has changed. Mutch more stable and more
reliable.

In the way you suggest, how does SS handle concurrency between pages.
Granted if I have one checked out, no one else can edit it, but what if I
need to compile and I'm calling a method on a page/class that someone else
is working on. How does it fare with making sure that what one developer
does doesn't adversely affect another.

When you work on isolated mode you actually are running all of it locally.
Basically you make checkins and checkouts, quite simple. All files of the
project are copied to the local project folder. When you run ur project you will
be actually running it on the local IIS. For example http://localhost/myproject

This wil enable each user tho debug and test individually the projects on the
local machine and may also increase performance on VS.NET.Not completly sure
because I never compared it. But at least you will be sure that it will reduce a
lot of problems.

I read somehere on the patterns and pratices that you should avoid using
smi.shared and shared options.

Here is some reading that i would recomend.

http://msdn.microsoft.com/library/d...SourceControlIntegrationInVisualStudioNET.asp

Hope this helps better than my limited experience with this

Regards

Joao Cardoso (MVP dotNET)
=======================================================
[LusoCoders]- http://groups.yahoo.com/group/lusocoders/
[PontoNetPT]- http://www.programando.net/regras.aspx
(e-mail address removed)-s.p-a.m - www.acinet.pt
=======================================================