A Single Developer's SharePoint 2007 Development Environment

Posted on 10/6/2007 @ 3:33 PM in #SharePoint by | Feedback | 9689 views

In this  blogpost, I will explain, what you need on your development machine, to be a productive SharePoint 2007 developer.

The Basic Environment:

As a plain vanilla .NET developer, what does your environment look like?

Well - that truly depends on the nature of the application you are developing. For instance, if you are developing a Windows Forms application, you could develop it on even Windows 2000 or XP. But if you are developing an ASP.NET app, you can develop to a great extent using the inbuilt web server that comes with VS2005. Of course you cannot be 100% confident that your stuff works, unless you test it on IIS. But if you were integrating with a third party solution, you will probably need that third party solution installed on your desktop too, right?

Similarly, for SharePoint, you need to develop on an OS that has SharePoint installed. So, your development machine will need to be Windows 2003/2008. Now, you could develop on XP, and port over the 2003 - but damn, why bother! Your MSDN license includes Win2k3 and you can use that in development environments, so why not just .. umm .. use it!?

Thus, the basic development machine you need should have atleast -

  • Windows 2003
  • SQL Server 2005
  • MOSS or WSS (whatever you are targeting)
  • VS2005
  • .. and a few other things (keep reading).

The Advantage of virtualization:

In a previous blogpost, "Tools of a SharePoint Consultant", I talked about why it is important to Virtualize. See, MOSS is a platform that can be used to target many different scenarios and business applications. Depending upon what exactly you are trying to solve, the setup might differ. Usually, you would want to switch between different MOSS installs to target different problems. Lets be fair, MOSS is a server based product, and airlines frown when you carry 3 blade servers and a huge power supply on an airplane. But Virtualization can help you mimic that environment on a laptop.

Is this typical to MOSS? I would argue that it isn't. While you could develop a simple .NET application on a real machine, remember you are comparing a bicycle (your hand written .NET app), to a 747 (MOSS). And as software is getting more and more complex, with the innumerable permutations and combinations of beta and RC software around, trust me, your real life will be a lot better, if you virtualize.

Okay, I will virtualize my MOSS basic environment, but how should that look like?

I am glad you asked. There are 3 scenarios you will need, let me describe them one by one -

a) A single machine with MOSS installed, and no domain.

This scenario is what you would use in 99.9% of the situations. There are extremely few use cases that will need anything beyond this setup, for a development environment. In the courseware that Carl and I put together, I use such an environment on purpose to illustrate how I "fake" stuff what I would have otherwise require an AD for.

For instance,

  • Instead of an Exchange server, you can use a POP3 + SMTP server.
  • Instead of domain accounts, you can use machine accounts (just type in <machinename>\<accountname> instead of <domain>\<account>).
  • Instead of profile import, you can use this open source tool I had written.
  • Instead of using Microsoft SSO, you can write custom SSO.
  • Instead of AD, use ADAM.
  • etc.

I am sure there are scenarios other than the above, but I would be hardpressed to find a scenario, that I cannot easily simulate in a single machine environment.

b) A single machine, that is a primary domain controller, and has MOSS installed on it.

Okay, for a certain borderline scenarios where you need to write AD aware code, and you really really need to play with the AD. Now, this is a very very very borderline case, but assuming that you _DO_ run into a situation, where you MUST have an AD. You may use this setup. This will run MOSS, but certain things in MOSS won't work, notably search.

Now, in all my play around with MOSS, I have ONLY ONCE ran into a situation where I had to use this setup. So needless to say, this is a borderline case. The specific case I ran into was that there was a client that wanted to manage site membership using AD groups, but ALSO wanted to see members list in a MOSS site. So I wrote a webpart to query the AD and display members of an AD Group. Again, I could have done this as a Console APP + Class library on Windows XP, and then tested it out on a physical (non-virtualized) staging environment - but I didn't have that luxury. It was just a lot easier to boot up my MOSS machine that was also a PDC.

Like I said "super-borderline-case".

c) Multiple virtual machines

I highly recommend checking out Scot's book's chapter 2 about how to setup such an environment.

This, I would qualify as less of a borderline case than "b" above. But still borderline. Scot chooses to use this environment in his book because he likes to teach with lawyer-like-perfection (and kudos to him for that). The following are some examples of scenarios which require seperate machines -

  • You wish to use Kerberos to solve the multiple machine jump issue in your code, and you need to have high confidence that your code works. Can't have high confidence, unless you see it work - can ya!?
  • You have a WCM scenario, and you wish to use content deployment paths. Again, can be simulated on a single machine, but you have high confidence once you test it on a multiple machine setup.
  • You wish to ensure that your custom code is stateless, and you wish to develop against multiple WFE's (overkill IMO - this can be easily tested on an integration environment (blogpost coming up shortly on various MOSS environments you need to have within a team).
  • .. other such situations.

Now, note, one theme keeps repeating above - "High Confidence". So again, if you had a non-virtualized integration environment in your team, you could develop on a single machine environment, and then test it on such an integration environment (See - Team based development environments). Even better, such deployment and testing can be automated. But if you must, rarely ever, you might need to run multiple VMs together.

I tend to avoid running this on my laptop, because multiple VMs run slow. I develop on a single VM ("a"), and then when I wish to ensure that my stuff works, I might test it on such a scenario. And usually in a team, I insist that we have such an integration environment available.

Okay, so how many VMs are we talking about?

I use VMware Workstation, so in my case only one :-). I simulate multiple situations/clients/code/setups using snapshots. In fact, I do that with all my VS2008 non-sharepointy work as well. My HOST OS is Vista Ultimate, and life couldn't be better.

But any given time, specific to Sharepoint I have atleast 4 that I can boot up in a matter of minutes -

  • The single machine environment with no domain - this is my workhorse machine.
  • The single machine environment with no domain and VSeWSS installed - I boot this up for code generation purposes (upcoming blogpost, and my course on DVD explains exactly what I'm talking about here).
  • Single machine + PDC.
  • Multiple Machines environment.

Over time in fact, I have created a SharePoint VM for every scenario I might need to solve. So if you need a BDC setup - I have just the machine for that. If you need WF's, I have just the machine for that. And if you need to have a brand new situation that I haven't faced before, I promise ya, I can setup such a machine, ready to go in less than 10 minutes.

Can you do that with a real machine? HECK NO!
And if you are still not convinced that you need to virtualize, seriously you need to stop sniffing that white stuff.

Okay lets summarize the single sharepoint developer's setup:

Definitely Virtualize, and use snapshots.

Have the following VMs ready to boot at any time -

  • The single machine environment with no domain - this is my workhorse machine.
  • The single machine environment with no domain and VSeWSS installed - I boot this up for code generation purposes (upcoming blogpost and my DVD explains exactly what I'm talking about here).
  • Single machine + PDC
  • Multiple Machines environment.

Each SharePoint install must have the following.

Great! But are things any different, when I have a team of SP developers?

Sure they are. As a team, you need to worry about other issues such as source control, versioning etc. What works better for a physical team that congregates in a brick and mortar building to develop together, is explained in this blogpost.

Sound off but keep it civil:

Older comments..

On 10/8/2007 6:53:38 PM Nicolas said ..
Thanks for this post Sahil.

I have a question.

Right now, a client wants to integrate Exchange with WSS.

i understand there asre some Webparts for this, but My environment doesn't have Exchange.

What should I do? create a VM with AD, Exchange and WSS, or create two: one with AD & Exchange and use my plain dev WSS VM?

On 10/8/2007 10:33:27 PM Sahil Malik said ..
Nicolas -

Exchange is heavy duty. If you can use a dedicated physical exchange machine I'd recommend that over multiple VMs.


On 9/20/2009 5:58:26 AM Steve said ..
What version of Windows Server 2003 is sufficient for VM SharePoint development? Standard (R2)/Web/SBS etc?

On 6/7/2010 10:12:45 AM Kent Lewis said ..
I am completely new to Sharepoint. I understand what it does but how to develop is a mystery at the moment. I have lots of experience with asp.net but I see the handwriting on the wall with regard to increased opportunities for future contracts as a consultant. I need to know this product and complement it with my asp.net experience. So I have questions. Is there a site where the SharePoint single user is available short of going the Technet subscription route? I have windows 7 for the Operating system. Is windows 7 as good a solution for the server as Windows 2003? Thank you