Creating A SharePoint Development Environment


As more and more .NET developers are beginning to develop custom SharePoint assets, a few common questions continue to be How do I set up a development environment? and What tools do I need?  Now, I know that beauty is in the mind of the developer and unfortunately size does matter.  Different size organizations have different policies but there are several requirements any environment should have.  Here is my own 2 cents in on a few aspects since I know a lot of folks don't want to read a lot of documents....I'm not sure what they do between 12:00 am and 6:00 am but it's definitely not reading.  But, again, these are my own 2 cents.  Check out the references and you will get a more complete story from folks much smarter than me.  I've also include references for tools you should also install.

 

  • First and foremost, you need to develop locally for the "best" debugging and testing experience.
  • Development is done in a virtual machine using the Win2003 OS and WSS/MOSS installed.  Each developer should have their own virtualized environment.  Have the virtual instance on a separate internal drive if capability allows or use an external drive.  Now having said this, you should know that I use both a virtualized environment and a standalone environment that has Win2003 installed directly.  In the latter scenario, I use a standalone Web server without a domain controller.  I have found that this is a very lean system and I can accomplish a lot of development without unnecessary overhead.
  • The host computer needs 4 GB of RAM.  Of course you can use 2 GB, but why???  In this case, more is better.
  • Establish a set of scripts to automate the configuration of your development environment.  Scot Hillier has an excellent set to get you started: SharePoint Development Environment Modifications
  • A Visual Studio development process that maximizes your productivity.  This will hopefully evolve as you do more and more development but I'd encourage you to check out my buddy Ted Pattison's STSDEV to get you started.
  • <update May 1, 2008>Since I posted this my buddy Andrew Connell has released a tool for building projects and solutions, SharePoint Project Utility Tool Window.  I've been using it recently and it's great as well.  It's awesome to see this kind of tool development by Ted and Andrew.  Great job guys.  Choices...choices...choices...
  • And for a great SharePoint development book, here you go.

</steve>

 

Environment Requirements and Overview

Setting Up Development Environments for the 2007 Microsoft Office System

Implementing Microsoft® Office SharePoint® Server 2007 and Windows® SharePoint® Services 3.0 Solutions

Team-Based Development in Microsoft Office SharePoint Server 2007

Development Tools and Techniques for Working with Code in Windows SharePoint Services 3.0 (Part 1 of 2)

Development Tools and Techniques for Working with Code in Windows SharePoint Services 3.0 (Part 2 of 2)

 

Building the Virtualized Environment

Use Virtual PC Differencing Disks to your Advantage

MOSS 2007 Development - Virtual Server Set Up

How to Create a MOSS 2007 VPC Image - the Whole 9 Yards

 

Configuration, Tools and Processes

SharePoint Development Environment Modifications

STSDEV: Simple Tools for SharePoint 2007 Development

SharePoint Project Utility Tool Window

SharePoint Server 2007 SDK: Software Development Kit

Windows SharePoint Services 3.0: Software Development Kit (SDK)

STSDEV: Simple Tools for SharePoint 2007 Development

Using Visual Studio 2005, MakeCab.exe and MSBuild to Create Window SharePoint Services v3 Solution Files (*.WSP's)


Comments (4)
  1. babler says:

    Steve,

    Glad I found you out here and I hope you are well.

    We are in the middle of a major MOSS implementation, which has a lot of custom dev work along with 50+ applications being migrated.

    Depending on the level of custom dev work, for anything mid to high I recommend the following:

    1. All developers have a virtual dev environment locally with MOSS.  They build and unit test here.

    2. They deploy to a dev farm that is backed up daily.  They have free access to configure what they need to get all the "pieces" working together with work other developers are performing.

    3. After bugs are fixed we roll to a staging environment that is tightly controlled.  This is also where integration testing occurs with other technologies (OCS, IDM, Exchange/Outlook, CRM, etc) as well as UAT.

    4. After UAT passes we roll to production.

    So basically I strongly advocate for any amount of medium to high customization for MOSS work that developers not only have their own standalone dev VM but also a shared dev farm to get all pieces working across development efforts.  We have tried the individual VMs going straight to staging and it has not worked out as well.

    Ben

  2. · Best Practices Resource Center for SharePoint Server 2007 · Tips for improving backup and recovery

Comments are closed.

Skip to main content