SharePoint Stack Exchange is a question and answer site for SharePoint enthusiasts. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

When doing development for SharePoint 2010 Standard and Enterprise features, should we use a farm or a standalone setup? Please note that a similar question was asked ,but this aspect was not taken into account. Thanks in advance

share|improve this question
up vote 0 down vote accepted

When developing anything for SharePoint it is always best to target the closest setup used on the live servers.

If this isn't possible, then usually the standard practice is a single VM possibly with an external database. You can then restore the VM and the database quickly while maintaining application speed. External AD and Exchange server is also a good way to go, creating a centralised hub for testing.

Then you have to decide what sort of solution you are going to use, depending on the features required depends on the feature deployment level.


@Ryan & in General, I agree the best productivity is where it is at. My issue has always been around topology issues where complex permissions are involved. For that reason, we use 24GB ram machines and run a virtual farm, one for each developer.

Not all companies can do this, but having a cloned virtual setup of live heavily reduces possible issues further down the line. When you are going into Enterprise development, having something that doesn't run like the live environment can and often does cost you extra time in my experience.

If you cannot run a clone of your live environment for development/testing, then always do try and get as close to the real thing as possible. +1 for the link Ryan.

share|improve this answer
Thanks for the answer;if we chose to use a server farm for development,do you think there exist best practices for building such development infrastructure? – sharePointer Oct 24 '12 at 12:24
Yes there is a standard structure that is used. 2 wfe, 2 app and 2 database, with indexer either running on wfe2 or on a seperate machine. – Hugh Wood Oct 24 '12 at 12:34
Hugh,your contribute is really appreciated;many thanks. – sharePointer Oct 24 '12 at 14:59

When developing you should, IMHO, use whatever has greatest productivity for your developers, even if this doesn't match your production servers.

For 2010 Standard this is running SharePoint on their desktop PC (enabling things like quick deploy, easy debugging etc etc).

MSDN - Setting up the development environment for SharePoint 2010

However, when doing testing/staging (stand alone/integration testing, QA, Staging etc) you should then use something that closely matches the production environment.

share|improve this answer
Ryan I agree with you;it is sometimes difficult,however,to find out what really improves productivity of your team without trying different solutions,unless your team is made up of experienced SharePoint Developers(which is not our scenario) I've read the article you mention above;at the end of the article a development farm environment is considered but without coming into details;I just wanted to know which are the best practices when choosing that approach. – sharePointer Oct 24 '12 at 14:54
Keep things simple, local install of SharePoint - will be quickest and easiest way for developers to work without extra un-necessary complexity of stepping on each others toes. – Ryan Oct 25 '12 at 11:58

One problem with a single development farm and multiple developers is debugging.

If one developer attaches a debugger to the IIS instances then it locks out the other devs from loading pages.

Also a dev server invariably has "Bad" and messy code on it including quick checks, proof of concepts, etc.

I've always gone for a single dev server per developer, this can be a virtual machine, a local install or any other method. Mine is a virtual machine on a big hyperV instance. Makes it easy to roll back when something royally messes the VM up.

Having a good working knowledge of the target architecture helps avoid surprises when you come to deploy to a test environment. It just takes a little thought up front in the design.

If your devs aren't SharePoint experts then make sure your applications designers (who write the detailed technical designs) are.

Also ensure you have at least one dev who IS a SharePoint expert who can code-review and mentor the junior devs. It's very easy to get into trouble with inexperienced SharePoint dev, such as not disposing objects, etc.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.