通过

Granularity of SharePoint Features and Solutions

  • 项目

In our SPG v1 guidance we discussed packaging site elements into features. This is particularly important if you are using the Visual Studio extensions for WSS. We found that whenever you add a site element into a VSeWSS project, a new feature is created for the site element. This lead to an excessive number of features that were too fine grained. Our guidance is to combine features into chunks of functionality that are generally self contained. You may still have some feature dependencies, but far fewer than if you had each site element in its own feature. You should expect to have just a few features in a WSP. But that leads to the next question: how granular should I package my WSPs?

I would imagine that if you are not using VSeWSS, you are likely to have just a few WSPs. Your decisions around how to organize your WSP likely depend upon release schedule and the need to run side by side (e.g. worflows). Now if you are using VSeWSS, you have another consideration. VSeWSS allows for right-click deployment and F5 debugging. This is a great feature, but what happens when you have a ton of web scoped features that are meant to be activated on different SPWebs? Same goes for features at other scopes. Right-click deploy (and F5 debugging) will deploy the WSP and activate all the features on the web URL specified in the “Debug –> Start browser with URL” value in the project’s properties. This is a great feature but if you don’t optimize your WSPs for this experience, you’ll have features activated in places you didn’t expect.

In our SPG v2 guidance, we are considering what our guidance should be in this area. Perhaps if you are using VSeWSS, you should optimize your WSPs for right-click deploy. In this case, you may have one WSP per SPWeb with unique functionality. But what happens when you have a site collection scope feature you want to deploy to many of these webs but these webs live in their separate site collections? Should the site scoped feature live in its own WSP? Hmmm…

Perhaps if you are not using VSeWSS you should optimize based on release schedule and need to run side-by-side. Not sure yet. If you have an opinion, please comment on this blog.

Comments

  • Anonymous
    June 10, 2009
    This week has been action packed with posts! Six ways to store settings in SharePoint by Wicton Wilen