>I presume by that you mean that it is recommended to work and test on separate workstations and update the server as needed.

Yes. I think VS supports a method where the project is on a shared server and each user can access it. You keep a working directory on your own machine and there is some way to update the shared server. I am not to familiar with it and doubt many people use it.

>Other than overwriting another's mods, are there any collision issues regarding IIS?

Well, with code-behind all of the code for all of the web pages is compiled into a single DLL. So, if Joe made a page change and tried to debug it, he may not be able to compile cause Jane edited a page and there is an error in it. Stuff like that.

>Does all of this get resolved with the use on the terminal server of Visual SourceSafe? (We are aware of Source OffSite and are considering it)

Using Source Control is always a good idea, even if you do use a shared project server. I don't think where VS is executing changes any of the project sharing issues.

My recomendation is to set up an environment where you have the following:

1. Developers Machines (with server) - each dev has a copy of the project on their local machine. The have access to all the source through some version control system. We use PVCS Version Manager.

2. Staging/Build Server - this machine runs automated scripts to build the project at a set time. We do daily builds at our shop. You can also set it up to build every time someone checks something in. The latter is usually refered to as Continuous Integration. The build machine and staging server are actually seperate machines in our shop... but they can be the same machine also. Programmers are basically not to check stuff in if it will break the build. On the odd occassion that the build doesn't work, and email is sent to all developers and whomever worked on the item that caused the problem can fix it right away.

3. QA Server - this machine runs a certain build. What the build on the staging server is considered stable enough to deploy to QA, that build is copied/moved to the QA server.

4. Production Servers - Once there is a version on the QA server that is considered 'release' quality (it could be from Alpha to Gold) it is deployed onto the production server. Since in my shop we sell our apps we don't actually have this. The 4th level in our shop is an install build to cut a CD. The CD is tested on a seperate QA server(s) in our test lab.

(Of course for a smaller shop 2, 3, and 4 can all be on the same PC, just serpate them logically on the hard drive.)

HTH,
BOb