Tips for organising your SharePoint project in Visual Studio

Becky Bertram recently blogged about Visual Studio project organisation for SharePoint. I agree with most of her points, and below are 3 additional conventions I’d suggest to others:

1. Always group SharePoint project items (SPI) into folders by project item types

Put all content type SPIs into a folder called ContentTypes, all site column SPIs into a folder called SiteColumns, and so on. This allows the content of the project to be more discoverable at a glance. For example, you can quickly get a high level idea of the content being deployed by the project below:

2. Always append the SPI type to the name of the SPI

If your project has a Feedback content type and a Feedback list instance, then name the project items as FeedbackContentType and FeedbackListInstance. Do this for all SPIs in the project. This helps identify the item in views such as the Feature Designer, and particularly the Package Explorer.

I find myself using the Package Explorer quite a bit these days. This is because Visual Studio automatically adds new SPIs to the last feature added to the project – and often this is not where you want the SPI to go. Using the Package Explorer, you can quickly verify the content of your features, and can easily cut/paste SPIs between features to correct the location of SPIs misplaced by Visual Studio.

3. Getting the feature boundary right

How many features should you have? Which SPIs should go into which features? These are the guiding principles I use to address these questions:

  1. Reduce the number of features where possible. The more features the more maintenance and administration overhead.
  2. Define feature boundary by functionality. Group SPIs related to a particular functionality into one feature. Each feature should represent a unit of functionality – the more coarse the unit the better. This is so that it may be possible to a) enable a functionality by activating only one feature, and b) deactivate the feature without affecting other functionalities.
  3. If a functionality could be reused elsewhere, group the SPIs supporting this functionality into their own feature. This is so that this functionality (and only it) could be activated in other locations (e.g. in a different site collection) without also activating other components that are not relevant to the functionality and the alternate location. Sometime ago I made a mistake of putting the masterpages, CSS, page layouts and other stuffs into one feature. After deployment, a new site collection was deployed to the same farm and needed to use the same masterpage to achieve the same corporate branding. We activated the feature I originally built, but this also deployed the page layouts and other stuffs that are not applicable to the new site collection.

After all however, I believe there is one rule that rules them all, and that is consistency. Whatever you choose to do, make sure you do it consistently.

Advertisements

About Bernado

Based in Australia, I am a freelance SharePoint and Dynamics CRM developer. I love developing innovative solutions that address business and everyday problems. Feel free to contact me if you think I can help you with your SharePoint or CRM implementation.
This entry was posted in Practices, SharePoint, SharePoint 2010. Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s