Summit 7 Team Blogs

SharePoint 2010 Development Environment

Developing solutions within SharePoint can be a daunting task when just starting out. I’ve worked with a number of colleagues, both junior level and seasoned professionals, who have developed with Microsoft technologies in the past. In each instance, there has always been a need to sit down with the developer and do a one on one walk through of their environment and explain the reasoning and benefits of properly laying out the environment before ever starting to put together a solution.

Development Best Practices

Before I start detailing out my actual development architecture and how I utilize each environment within that architecture, I wanted to cover a few high level development topics which are a must for anyone that is new to SharePoint development. As a starting point, I wanted to highlight some key development best practices that are more thoroughly explained by Gayan Peiris at his blog. It’s a great blog post and from that, the following are very relevant to how you should go about configuring your development environment.

1. Plan ahead. Don’t let the ease of user of SharePoint Products and Technologies guide your development. In other words, just because it’s very simple to set up a SharePoint instance running on a single server, it doesn’t always mesh well or properly mimic your production environment, either of which could cause major headaches and embarrassing failures when it comes time for deployment to a client’s production environment.

2. Until your code is running as expected, avoid using production components (such as Active Directory) in development environments. In simple terms, make sure your business logic is as complete as possible and correct before trying to implement complex security trimming or cross domain authentication.

3. Avoid logging events in the operating system event files, because in case of a problem – it is hard to detect operating system issues. Additionally, SharePoint 2010 has made great advances in the capabilities of logging from within SharePoint which can be found in better detail here. Most notably is the addition of the Correlation ID, which provides a direct look up within the SharePoint logs to better debug issues that occur.

4. Clean up/dispose of SPWeb and SPSite objects (for more information, see Best Practices: Using Disposable Windows SharePoint Services Objects). This is a foundational principle of SharePoint development that simply can not be emphasized enough. In relation to our topic, be sure to utilize 3rd party tools which monitor the clean up of the necessary objects which will help you create more robust and stable code.

6. Avoid any direct access to the SharePoint databases. Accessing these databases programmatically or manually can cause unexpected locking within Microsoft SQL Server that can result in overall performance problems. Aside from any locking issues that might occur, it’s my understanding that Microsoft will withdraw all support for your SharePoint environment if any direct change is made to the SharePoint database. Not a good situation.

Development Environments

With the development formalities out of the way, we can focus more on the actual architecture of a development environment and how each environment is utilized based on the functionality it provides. The following is a diagram of the separate development environments and how they are incorporated into my development process from solution conception to final delivery:



Single Server Development Farm

The primary purpose of the single server development farm is to allow for the production of a quick development task which doesn’t require the full implementation of external services or advanced configuration of SharePoint Service Applications. The single server development farm is also great for throwing together a quick prototype or proof of concept solution which allows you to test the functionality of a capability within SharePoint.

With regards to functionality, the single server development farm contains the following applications. The list can vary but the intention is to provide the necessary capabilities to build out a small solution.

As the development for solutions are completed within this farm, the solutions could be deployed to two different environments, the Multi Server Development Farm or the Multi Server Integration/QA Farm. Solutions should be deployed to the Multi Server Dev. Farm if it is determined during the initial development or proof of concept that there is a dependency on a more advanced capability such as Active Directory, a full SQL Server instance, a SharePoint Service Applications, and much more. This scenario would allow for the full test-out of the component and further development as necessary to complete the functionality.

In situations where the developed solution is indeed simple enough to not warrant the integration with advanced capabilities of SharePoint 2010, it would be perfectly acceptable to progress the deployment of the solution directly to the Integration/Quality Assurance Development Environment.

Multi Server Development Farm

Like the single server instance, the Multi Server development environment contains the full set of required tools that are used to produce robust SharePoint 2010 based solutions. As mentioned before, the key differentiator with this configuration is the availability of advanced capabilities that SharePoint 2010 has to offer. It should be noted however, in order to utilize multi server development environments, there is a substantial need for greater hardware capabilities to support the multiple servers. There are numerous posts out there that detail the use of virtual environments for development platforms so I am going to skip focusing on that point in great detail. I want to be sure to point out though that I’ve utilized the VMWare Workstation application for a number of years and I’ve been completely satisfied with its functionality. You can find more information on VMWare Workstation at

The capabilities of a multi-server environment surpass those of a single server environment in that the addition of servers allow for the distribution of the environment’s functionality across multiple servers. For example, in a three server configuration, server one could contain a domain controller and an instance of SQL Server, server two could contain a SharePoint Web Front End, and server three could contain all the required SharePoint Service applications and a search indexer. In this scenario, a developer could have Visual Studio installed on server two, the WFE, and the responsiveness of this server will not suffer during search indexes or due to the processing of data within the SP Service Applications. As you can imagine, there are an infinite number of server configurations that can be defined for a development environment but often times, it will be determined during the discovery and requirements phase for a solution which advanced capabilities of SharePoint will be required. Based on the requirements, it is perfectly acceptable to begin the development of a solution directly within the multi-server development environment. In reality, much of the work that I do begins here as my solutions tend to involve multiple aspects and functionality of SharePoint.

In summary, the Multi Server Development Farm should be an advanced and highly capable platform with which you can develop your SharePoint 2010 solutions. In utilizing this environment, there will be many similarities in capabilities with a number of standard SharePoint 2010 production deployments.

To be continued…

In my next post, I’ll expand more upon the final two development environments, the Multi Server IT Pro Farm and the Multi Server Integration/Quality Assurance Farm. Each of these environments serve their own unique purpose. In an effort to keep my posts as a relatively easy read, I will follow up with more details in the coming days.

If you have any comments, issues, or additional advice about your SharePoint development environment, I’d love to hear them. Feel free to post any feedback you have in the comments below.


This post is cross-posted from

About Jason Cribbet

ason is a Solutions Architect with more than 14 years of software development experience within the Microsoft technology stack. He brings to Summit 7 Systems his experience architecting and developing web applications in SharePoint and Office365 for commercial clients and within the federal space which requires strict software development process definition and CMMI compliance. His technical skills include User Experience design and development, client side technologies, .NET and web based development, workflow, and dash boarding capabilities as part of the complete software development life cycle. Jason’s educational background is in computer engineering from the University of Central Florida in Orlando, Florida. He’s considered by many to be the better looking and stronger ‘Jason’ within Summit 7.