I'd recommend having local EPiServer installations on each developer machine for debugging and stability purposes. Each developer can make breaking changes on his own machine, without affecting the other developers on the team. Working in a Front Page Server Extension environment (one developer server, one source, multiple developers) is not that straight forward when using a compiled language. One developer can make breaking changes that directly affects the other developers on the team. Even making the project uncompilable for a period of time. Each compile will - as you know - tear the site down, affecting the performance for anyone that is using the site. However - all developers on one team can use the same database.

Hi and thanks for your rapid answer. Is this the correct order of configuration of a team development environment: 1. Install EPiServer on a central development server housing both database and application. 2. Creating a Visual SourceSafe project from the development server copy of EPiServerSample.csproj. 3. Install EPiServer on each developer machine, using the central database created in step 1. I assume this is necessary to get the EPiServer assemblies installed in a correct fashion. 4. On each development machine, create a local blank solution and add the EPiServerSample.csproj from Visual SourceSafe created in step 2. TIA Jonas

The order of configuration seems logical. I would recommend adding the project to VSS from one of the developer machines, directly from VS.NET. If you don't absolutely need to use it - stay away from the VSS IDE - it does not have the neccessary information about file dependencies that VS.NET has (aspx, aspx.cs, aspx.cs.resx etc.) Checking in and out from the VSS IDE can break the VS.NET project (forcing you to remove and add it to VSS all over again.) Assign one developer the role of Build and Deployment Manager, who will be in charge of building and deploying to the development server in regular intervals. (Get All Recursive, Compile and Copy Project). Automated nightly builds is also an option, but requires more effort on the setup side. Avoid having EPiServer files in your VSS project (like admin, edit, util, webservices). You can put /bin into VSS, but it is not recommended to have binary files in VSS, and is seldom neccessary. Copy the EPiServer files from another installation to have a running site. If you do an EPiServer installation on the development machines, EPiServer will register its assemblies into the Global Assembly Cache, which is preferred in a development environment. (You'll avoid the pesky "Can not Access File 'AssemblyName' Because It Is Being Used by Another Process" problem described in FAQ article Q3782: http://www.episerver.com/templates/faq____3782.aspx)

I tried out my configuration order, but ran into a little problem when I tried to get the EPiServerSample.csproj from VS on a development machine. When adding it to the solution from VSS, it "collided" with the project placed in wwwroot by the EPiServer Installer. I guess I have to try to just delete those files and then add the project from VSS, but it would feel better to have a "correct way" of doing it without a lot of hacking .... or should I perhaps just manually copy the EPiServer assemblies from the development server to each development machine and then get the VSS project instead of installing EPiServer locally. /Jonas