Deploying an application : Why not use SharePoint Publishing API ?

Dec 2, 2008 at 11:47 PM
Edited Dec 3, 2008 at 5:22 PM
Why can't we just use SharePoint Publishing API with ExportChangeToken to deploy an application and application updates ?

What do you think about this article ?

Dec 5, 2008 at 6:00 PM
I think you can read from chris' blog posting why you might choose content deployment over features. The main point chris is trying to point out is features and site definitions are useful when creating multiple sites in a templated way. Also WCM is really a feature of MOSS and not WSS. You'll see that the guidance in this version is really meant for WSS and doesn't deal with MOSS features just yet. There's many ways to skin a cat, deploying features using the solution infrastructure is the approach that worked for us and we feel confident in recommending.
Dec 10, 2008 at 4:00 AM
So, if I creat a Site Definition and creat a new Web Site and subsites from this Site Definition and want to update my Web Site(s), you recommend to use Feature.

But, for example, if I just want to add a new List at a specific spot on each page of the Site and subsites, what will be the best approach ?

1- Coding all changes to the Web Site(s) in a Feature.
2- Create a Feature to deploy the List, do the changes in the Web Site and subsites using the UI of SharePoint and use the content deployment to export/import the changes.
Dec 10, 2008 at 11:51 PM
Since v1 version of guidance is meant for WSS and does not require MOSS (which has WCM publishing feature), I would recommend coding all changes to in a Feature. the next version of Guidance will address the MOSS features such as WCM.
Dec 15, 2008 at 2:55 PM
The solution discussed in (2) above becomes a maintenance issue if your application depends upon someone correctly making the changes via the UI across all sites.  Additionally how would you enforce adding the list for newly created sites based on the sitedef if you truly consider the list part of the application?  Whether or not publishing is used, this ends up being an issue IF you consider that list part of your application.  If you do, we would recommend doing the updates in the application in all cases for both existing and new sites, and not through the UI.  If you do not consider the list as part of the application (meaning the application works fine and is complete without the list, it is ancillary information, and its not important that new sites have the list), then that may be more suitable to solve by investing in MOSS and using the publishing infrastructure if this is a common scenario for you.

If the capability IS considered part the the application then we'd think about it as follows...

There are two things you need to consider when updating functionality - 1) getting the new fuctionality added to existing sites  2) have newly provisioned sites include the functionality.  You need to take actions to acheive each of these.  As a general rule, we always recommend making the changes in the application logic if this is a capability that you consider a part of your application functionality. 

There is a larger topic of solution factoring that needs to be considered.  When creating features, you should determine if the features themselves stand up as a set of functionality.  If the updates are instead part of update to the existing features, then we would recommend updating the existing features and redeploying, otherwise you'll run the risk of creating an incomprehensible mix up of features in the long run.  We cover that area in in the guidance. 

More generically, in order to add the functionality to an existing site, generally you'll need some smarts in a feature receiver to discover the sites that have been created and make the updates through the SharePoint OM.  If the functionality sits beside existing functionality (does not need to alter any of the existing assets including defniition files of the deployed application), and stands up as a feature (set of logically grouped and useful functionality), then this can be done through a combination of deploying the new feature and stapling the new feature to the existing site definition.  Your feature receiver will need to be smart enough to detect between these two cases (running on a new site vs. initial installation) and take the appropriate actions.  We cover this area in the guidance.

If you need to update functionality in the existing sites, then you'll need to add the functionality to the existing features, update the sitedef if necessary, and redeploy.  There are a few ways of doing this that we describe in the documentation.  Since the sitedef only impacts new sites, you will need to update the existing sites through a feature receiver as well if you want to add capabilities.  There is a lot to this area, and we document it in the guidance.  While its hard to say without knowing all of the details of a particular situation, the example you've cited feels more like this case.