WSS/MOSS Development Environment

[nt1]

Hello

We've got a project coming up, which will be developed on MOSS 2007 and
ASP.NET for additional functionality.

We are currently planning the development environment we'll need for a team
of 3 developers. Normally we would have a development environment set-up on
each developers machine and each developer would check-in their work to
source control.

Developing using MOSS 2007 doesn't seem to be that simple, as a lot of the
content and pages is actually stored in the database.

How are people managing the development environments for MOSS 2007 and
Source control.

Thanks

[Zandy]

I haven't tried this out, but it just might work... :)

I would do the following:

Setup SharePoint on each of the developer's machines - this is really the
best practice when developing on SharePoint as it becomes painful to try and
share a MOSS instance between multiple developers. Furthermore, it makes
debugging much easier to have your own instance of SharePoint when developing.

I would set up a central SQL Server and each of the developers instances of
SharePoint would hook up to the central SQL Server so they are all sharing
the same instance of SharePoint.

WebPart development would be done on each developers workstation and hooked
up to a source control repository as normal.

You'd also need to share a common web.config file for the portal that you're
working on, so that would need to be synchronized as well.

Does that help?

Zandy

[Paul Stork]

I normally recommend the following.

1) Setup each developer with a PC hosting 2 virtual machines (You can use
either Virtual PC or VMware). One of the virtual machines should be Server
2003 running SharePoint, SQL, and Visual Studio. The other is a standard
client for your environment, usually XP.
2) Each developer programs custom webparts,site definitions, etc. on their
own Virtual copy of SharePoint. This makes it MUCH easier to debug since
they have total control of the server and can debug code locally rather than
remotely. SharePoint development will require relatively frequent IISresets
or AppPool resets. This would disrupt other developers if they are on a
shared server.
3) Once Debugged test code by using the Other virtual machine (XP) to make
sure that remote access to the web part etc doesn't cause issues.
4) Move the code to a shared test server that duplicates your production
environment. Do final testing and deployment from here.

Hope that helps.

Paul Stork
"nt1" <n...@discussions.microsoft.com> wrote in message
news:45C99317-D107-4BAC...@microsoft.com...