Take the 2-minute tour ×
SharePoint Stack Exchange is a question and answer site for SharePoint enthusiasts. It's 100% free, no registration required.

Are their any best practices with respect to how to structure a SharePoint solution?

For example we are going to develop several workflows, these will use content types and list definitions.

Should we group each type of content, for example all content types, in a single project. Or should we group everything that is used for a workflow in one project?

share|improve this question

3 Answers 3

up vote 9 down vote accepted

When working with SharePoint 2010 and the Visual Studio Tools for SharePoint, you can effectively structure your project how you like - this is because you can use folders to structure things logically, whereas in the past with SP2007 WSPBuilder projects you would typically mirror the 12 hive structure.

One option is to use folders for the different artifact types (e.g. content types, fields, list defs etc.). However, another choice might be to group things by functionality - it really comes down to what makes the most sense for you. In both cases, you can map things to whatever set of Features you like in the Feature Designer (or by editing the Feature files by hand).

Some considerations I use when structuring things, Features in particular:

  • IMHO, code workflows should always go in a separate assembly (or assemblies) to your other artifacts, since if you need to upgrade the workflows, you'll probably want to version the assembly so you can create a new SPWorkflowAssociation. You may not want to version the assembly with all your other artifacts in at this time since that might break things (without further mitigation at least).
  • Feature scope - some artifacts such as fields/content types are Site-scoped, whereas others such as list instances are Web-scoped. This often leads you to structure things in a certain way even when you actually wanted them in the same Feature.
  • Feature dependencies are useful to e.g. have a Feature which deploys a list instance depend on the Feature which deploys the Site-scoped fields/content types
  • SharePoint 2010 introduces Solution dependencies. Similarly these can be useful to have your WSPs depend on say, a core WSP which deploys supporting artifacts (though note you can retract a depended-on WSP, the check only happens at deployment time)
  • SharePoint provisions artifacts in a Feature in the order they are declared. The Feature Designer has Up/Down buttons to move artifacts around (lots of people seem to be missing this), allowing you to ensure that where a Feature deploys some related artifacts, the provisioning happens in the correct sequence.

Part of it is understanding that a particular VS project's logical structure (folders) doesn't need to map too closely to the Features - you can map between the two however you want, subject to some of the constraints listed here.

share|improve this answer

Probably best to package your list definitions, content types and workflows into Features (3 Features, one for each of the above), and then wrap those features into a WSP Solution package.

This allows you to easily deploy your solution, as well as making upgrading of any one component a lot easier.

share|improve this answer

Have a look at the SharePoint Development Guidelines I wrote some time ago. It is available for free.

It doesn't have any specific guidance on content types though, but they will fit in the project structure defined in the document.

share|improve this answer

Your Answer

 
discard

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.