locked
Understanding Installation Flow for Custom lists RRS feed

  • Question

  • Hi,

    I want to create a solution that will perform the following steps;
    • Create custom columns then;
    • Create an instance of a custom list using those columns then;
    • Create an event handler which will populate the new list

    OK, so I can perform these actions individually by using features and assigning an event handler by code - question is;

    How do I package these steps up into a solution that will perform the steps in the neccessary order so dependencies are honoured ( such as the existence of the custom column before list created or exisitence of the custom list before event handlers are attached) ?

    Thanks,

    Macintos

    Tuesday, October 28, 2008 7:42 AM

Answers

  • Ahh .. I think we are talking about 2 different things ...

    Solution Package (WSP File)
    a Solution Package is used to deploy files which have been developed into a SharePoint environment. They are typically used to do the following:

    * Copy assembly files (DLLs) into the GAC and application Bin folders
    * make amendments to the web.config to register assemblies as "safe"
    * Copy files and folders over to the SharePoint "Template" folder
    * install "Features" which have been copied over, so that they are available to be "activated" within sites.

    Features
    These are the mechanism by which you turn things on-and-off in your SharePoint environment. Features are first copied over to the SharePoint server and then "installed" (see the Solution Pack above).

    Once a feature has been installed it becomes available to be "activated".

    When a feature is Activated it ... does things ... there is a wide variety of things you can do when activating features, but a short list includes:

    * Create new Site Columns and Content Types
    * register new List Templates which can be used to provision new lists
    * register event handlers and workflows, associating them with content types and list template types
    * create (or hide) custom actions, extending the menus in SharePoint
    * execute custom code ... which is where the fun really starts!

    The "custom code" is executed using a class known as a Feature Receiver (see SPFeatureReceiver on the WSS 3.0 SDK). They are basically event handlers for features, so you can trap "Installing", "Activated", "Deactivated" and "Uninstalling" events.

    Each feature can have one or more "activation dependencies" which are basically rules which state that a feature cannot be activated unless one or more other features are activated first ...

    Hope this gives you enough of a grounding to get going ...

    regards
    Martin Hatch
    MCPD .Net Web Development
    MCTS WSS 3.0 | MOSS 2007
    Visit my Blog
    • Marked as answer by Mike Felton Wednesday, October 29, 2008 5:39 AM
    Tuesday, October 28, 2008 11:58 AM

All replies

  • You cannot typically have 2-levels of activation dependencies, but this shouldn't be a problem:

    3 Features

    1. customFields [Hidden] [Site]
    2. customList [Hidden] [Web]
    3. customListInstance [Web]


    The customFieds feature should create all of your Site Columns. The customList feature should be a list template which contains the configuration for your custom list (including views, column metadata, etc). Both of these features should be hidden.

    You can then create the "customListInstance" feature. This would basically consist of a "ListInstance" feature to create a new list using your custom list template. You can either attach a FeatureReceiver (OnActivated) and populate the list data through code, or you can use the <DataRows> fields in the CAML of the ListInstance and pre-populate your data there!

    Now, to ensure that everything is setup in the correct order you would normally set a Feature Activation Dependency targetting features 1 and 2.
    Now, because feature 2 is in the same scope (Web) and is hidden it will automatically be activated before your list instance feature activates!

    But ... you can't do that with Feature 1 (because it is at a different scope - Site) .. so you will need to make sure that feature is activated at the Site Collection level first!
    The alternative is to scrap the Feature Activation Dependencies and just activate both features through code using your Feature Receiver!

    Hope that helps!


    regards
    Martin Hatch
    MCPD .Net Web Development
    MCTS WSS 3.0 | MOSS 2007
    Visit my Blog
    Tuesday, October 28, 2008 10:25 AM
  • Martin,

    Thanks for the reply - I'll take a look at the feature activiation dependancy as you mentioned.

    Sorry I should have been more clear on the third step : what I meant was that after steps 1 and 2 are complete I wish to deploy an event handler ( disregard what it actually does for now, just that it needs the previously created list to function corrently)

    Just so I've got it clear in my head on the approach - I uderstand that the feature activiation dependancy could handle steps 1 & 2 but my event handler is a DLL that will need deploying to the GAC etc. after this is complete.

    Is this what the wsp package will do for me or can an event handler be deployed in a feature ?

    Sorry for my confusion.

    Macintos
    Tuesday, October 28, 2008 11:44 AM
  • Ahh .. I think we are talking about 2 different things ...

    Solution Package (WSP File)
    a Solution Package is used to deploy files which have been developed into a SharePoint environment. They are typically used to do the following:

    * Copy assembly files (DLLs) into the GAC and application Bin folders
    * make amendments to the web.config to register assemblies as "safe"
    * Copy files and folders over to the SharePoint "Template" folder
    * install "Features" which have been copied over, so that they are available to be "activated" within sites.

    Features
    These are the mechanism by which you turn things on-and-off in your SharePoint environment. Features are first copied over to the SharePoint server and then "installed" (see the Solution Pack above).

    Once a feature has been installed it becomes available to be "activated".

    When a feature is Activated it ... does things ... there is a wide variety of things you can do when activating features, but a short list includes:

    * Create new Site Columns and Content Types
    * register new List Templates which can be used to provision new lists
    * register event handlers and workflows, associating them with content types and list template types
    * create (or hide) custom actions, extending the menus in SharePoint
    * execute custom code ... which is where the fun really starts!

    The "custom code" is executed using a class known as a Feature Receiver (see SPFeatureReceiver on the WSS 3.0 SDK). They are basically event handlers for features, so you can trap "Installing", "Activated", "Deactivated" and "Uninstalling" events.

    Each feature can have one or more "activation dependencies" which are basically rules which state that a feature cannot be activated unless one or more other features are activated first ...

    Hope this gives you enough of a grounding to get going ...

    regards
    Martin Hatch
    MCPD .Net Web Development
    MCTS WSS 3.0 | MOSS 2007
    Visit my Blog
    • Marked as answer by Mike Felton Wednesday, October 29, 2008 5:39 AM
    Tuesday, October 28, 2008 11:58 AM