Automating WSS v3/MOSS 2007 development environment setup: Part I – Planning


Recently, I advised customers on their development environments. Many different options are possible and each choice done brings benefits and limitations. In this post and few others to follow, I will discuss the main options, with their impacts, and then describe how to automate the setup of the developers’ environment, to insure the use of these choices in a consistent manner.

This first post discusses the different main options to baseline a development environment for SharePoint Products & Technologies.

When having a look at Microsoft guidance on MSDN, you find relevant contents:

1.      Setting Up Development Environments for the 2007 Microsoft Office System ( this article gives good information, but is NOT adapted to SharePoint development


2.      SharePoint Team Based development ( completed with
Development Tools and Techniques for Working with Code in Windows SharePoint Services 3.0 (  Interesting to help team understand the process, the delivery packaging and which environment to setup. These articles are just completed by this one, released recently : Using Team Foundation Server to Develop Custom SharePoint Products and Technologies Applications

Additionnaly, a new MSDN highly valuable article is available on SharePoint Guidance, from the Patterns & Practices group. You’ll find these informations here: 

As synthesis, I often go to these 2 main options presented to customers:

·         Option 1 /Working Locally = Dedicated VM per developer + common hardware to support functional services (like SQL, Source Control, development domain ….)


·         Option 2 /Working Remotely = 1 Physical server hosting development environment, and developers working through Terminal Server/RDP Client on the machine

Option 1 is adapted to most of developers’ needs, and customer’s situation (it’s the 90% of the recommended cases). My favorite option for sure.

Option 2 is adapted if hard security or few rights are allowed to the developer on its workstation. The main disadvantage of this option is the Memory need, as 1 development environment loaded could exceed more than 1.5 GB RAM need => 10 developers would need up to 15 GB of RAM on the server ? …. Any budget for this?

 Now, that we talk of “Working Locally”, there is a lot of questions to be answered to setup the environment:




Base environment components

       Windows Server 2003 SP1 or higher

       SQL Server 2005 SP2 or higher

       WSS v3 SP1 + Infrastructure Update


       MOSS 2007 SP1 + Infrastructure Update

       Language Packs needed

       .Net Framework 3.0 SP1 or higher

Be sure to get SQL Server Management Studio (with SQL Profiler) to track data connection between SharePoint and SQL Server

Source Code Management system

       Team Foundation Server

       Visual Source Safe

       Any others

To use TFS, you’re not obliged to have dev machines in the same AD domain (but you’ll need to authenticate on the TFS server)


       For stand alone : almost always yes (dual boot is a burden)

       For Team based: you should probably share components and put them in a physical environment. For example, you can dedicate a box to host the DC+SQL Server roles for the development team/domain

Be careful enabling Domain Controllers for “development” domains in an Enterprise managed network: don’t disturb the production domain, watch the DHCP server settings, etc ….

Development output

Use WSP packages!

More Info here:

Development Core software

       Visual Studio 2005 + VSeWSS v1.1 + WWF extensions for VS 2005


       Visual Studio 2008 + VSeWSS v1.2

VS 2005 SP1 is not mandatory

VSeWSS stands for Visual Studio extensions for Windows SharePoint Services (can be found here)

Platform technology

x86 for sure !

Visual Studio is x86 only application and VSeWSS won’t install on x64 platforms.

If deployed on x64 platform, the JIT will compile it on the fly (you must be careful of your project options in Visual Studio anyway)

Domain or Workgroup

That is the question!

       If you plan LDAP use, user profiles tests/use, or spanned server roles on different machines you need Active Directory

       If choosing Workgroup, everything on the same box is mandatory

For enterprise work, go for Active Directory (beware that Document Conversion don’t work if SharePoint is hosted on a DC !)

For personal development, perhaps workgroup is enough, but you’ll miss the LDAP and User Profiles features.

Most of my colleagues run with Domain dev environments. The Microsoft WSS v3 developer VHD runs in a Workgroup.

Office System software products

       Office Suite (a version that maps your user’s environment). Have special attention to InfoPath

       SharePoint Designer 2007

Check what IT admins decided regarding the deployment of Office and SharePoint products (like SharePoint extensions)

SharePoint installation

Full is the best option (everything except SQL server)

Autonomous can be option: but it will setup SQL server express with a specific instance called OFFICESERVERS. But you won’t benefit the SQL tools like SQL Profiler and Management Studio. Once setup with this option, some parameters are locked in the farm so that you can’t change the SQL instance.

Additional Tools

      WSS v3 + MOSS 2007 SDKs


       Notepad ++

       WSPBuilder (if needed see below)


       IE Dev Toolbar

       Firefox + Firebug

       SharePoint Manager

       Codeplex projects

       Microsoft Network Monitor

       Any third party tools


There are a lot of possible tools. Any developer its choice and habits.

The list here is just ideas …

Here is a Codeplex project that may help : SharePoint Visual Studio Project Templates 

SharePoint development methodology

Help yourself and make your own opinion:

       Ted Pattison method :

       Scott Hillier method :

       Andrew Connell method :

       Any others you find or build J

You can read this interesting post from Scott on VSeWSS here : Is VSeWSS 1.2 Ready for Prime Time?

This way of doing development is really up to you. The most important is the output = WSP files ….


That was a little journey in the great world of tools to develop on SharePoint. You may think its complex, and you’re right. Next release should ease this aspect as SharePoint development was understood to be too much complex. What will help: Visual Studio next version, or SharePoint Designer 14? Who knows?

In my next post, I’ll give you the description of the platform I use, and how to have it “up and running” an automated way.

Best Regards,

< Emmanuel />


Being concious of issues creating and developing solutions on MOSS, Microsoft started this new MSDN section : SharePoint Guidance ( This a very positive initiative.

You should especially have a look at this page : Creating a Development Environment ( , even if it’s very generic information.

Comments (3)

  1. Hi, This long post series raised interest from many of you. Thanks for that. I was asked few times to

  2. Un petit post rapide pour linker une excellente série faite par Emmanuel Bergerat sur son blog : Automating

  3. Un petit post rapide pour linker une excellente série faite par Emmanuel Bergerat sur son blog : Automating