SharePoint Development Best Practices

Presented by:

Kirk Evans, Architect Evangelist, Microsoft,

Chris Keyser, Best Practices Team, Microsoft,

More of a focus of best practices they learned in 2007, and how it will be applicable to 2010.


Basically use WSP's for all deployments. It's actually a CAB file. Has everything needed for the deployment, and allows you to add and delete it from the Config DB. This then allows the administrator to deploy and retract on all web front ends. Also when a new front end is added it automatically get's deployed. Also allows the deployment to be done separately and scheduled later in the evening. Gives the administrator a warning if something is getting installed to the GAC.

Development Environment

You should always develop on a stand-alone server, preferably a single developer per server.

Use a build and CI server.

You don't want to work in a shared environment due to IIS Resets. Debugging is also an issue, if someone hits a breakpoint, then that will stop everyone else on the machine.

Metal install

  • Install on Vista, Windows 7, Windows Server 2008 R2.


  • Windows Server 2008 R2 Hyper-V role.

Boot to VHD

  • Windows 7 boot to VHD
  • Windows Server 2008 R2 boot to VHD

Application Lifecycle Management

  • Dev Machine
    • Visual Studio 2010
    • SharePoint Server 2010
  • Team Foundation Server
  • Build Server
    • Has Build environment and SharePoint 2010 DLL's
    • Gets code from TFS and then does the build and executes the CI test
    • Builds the WSP's and checks them in to the Repository automatically
  • Staging
    • WSP's from TFS are deployed and allow for testing

WSP doesn't get checked into TFS. There is a build definition for the project, and under the process tab there will be a section called 3. Advanced there's an option called /p:IsPackaging=true. This will cause it to generate the WSP. The nightly build is what creates the WSP and puts it in a drop folder with date labeled folders.

More information this is the SharePoint application lifecycle management resource center


Unit Testing

Do More of it.

They release code every two weeks, and then gather feedback. Unit Testing can be done in any development process, it's not unique to Agile or Extreme development.

Unit Testing – The Code is doing what the developer intended it to do. Should run against a substitute for the real system.

Acceptance Test – The Code meets the business users requirements.

Effeciencies come later in the cycle, there is a cost up front, but during integration both at the end and during development you have fewer problems.

Integration Testing – Operates against an actual real system.

Patterns help isolate code to improve testability. By isolating the code you can test it successfully without a lot of extra effort. MVC is a good example of a pattern that facilitates testing.

Need to look at the presentation video, at this point he demonstrates how to do a unit test with TypeMock. It's a very good example, he takes code that's monolithic and shows how to refactor it to the MVC pattern. He used XUnit to perform write the tests.

Nice new refactoring tools in VS 2010.

Load Testing

What: Allows you to identify performance bottlenecks and memory leaks.

How: Use Visual Studio and Team System Web Test.

Watch the video for the next part.

Defensive Coding

Avoid long debugging sessions by coding defensively.

  • Understand how the API's work
  • Don't re-invent the wheel, SharePoint has logging already built in that works with existing log tools


  • Don't alter the SharePoint schema, assume it will change.
  • Use facilities that already exist, such as ULS logs, instead of building your own.
  • Limit amount of work performed in an event receiver.
  • Limit work performed in an HttpModule
  • Don't evaluate List.Items in a loop expression. (Use the SPListItemCollection, it caches the list data locally)
  • Dispose of types correctly.
  • Use SPDisposeCheck.

Important point, if you do dispose something that does not need to be disposed, it can cause stability issues with the site. Use SPDisposeCheck to be sure.

The code analyzer in Visual Studio is FXCop. SPDisposeCheck will catch things that the code analyzer will not catch.

Oooh, there's an add-in for SPDisposeCheck!!!