Upgrading Standard List Definitions
This content is outdated and is no longer being maintained. It is provided as a courtesy for individuals who are still using these technologies. This page may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.
List definitions in Windows SharePoint Services 3.0 have been moved into Features to make them more easily accessible from site definitions. For this reason, you no longer need to redefine lists that you do not intend to customize within your site definition.
If you have not customized any standard list definitions, simply remove the standard Windows SharePoint Services 2.0 list definitions from your site definition and replace them with a reference to the standard Windows SharePoint Services 3.0 team collaboration Feature.
To remove the standard list definitions from your site definition
Remove the <ListTemplate> tags in Onet.xml for the following list types:
Remove the supporting list directories for these Windows SharePoint Services 2.0 list definitions. That is, for your Windows SharePoint Services 3.0 site definition, you can remove the Windows SharePoint Services 2.0 ANNOUNCE, CONTACTS, CUSTLIST, DISCUSS, DOCLIB, EVENTS, FAVORITE, GRIDLIST, IMGLIB, ISSUE, TASKS, VOTING, and XMLFORM folders from \LISTS.
In each of the <Configuration> tags within your Onet.xml file, add a reference to the team collaboration Feature, as follows:
If you have customized specific list definitions (for example, the document library definition [DOCLIB]), then you must use a more piecemeal approach. Replace all the uncustomized lists as mentioned above (in this case, all lists except DOCLIB). Rather than adding a reference to the team collaboration Feature in your <Configuration> tags, add specific references to the Features that contain list definitions you have not customized.
The following table shows the Feature folder names and Feature IDs of list definitions:
If you have only customized the document library (DOCLIB) list definition in your Windows SharePoint Services 2.0 site definition, do not include a reference for this list definition within the <Configuration> tags of your Onet.xml file. Add Feature references that are scoped to a site collection or Web site level for every Feature except the document library definition, so that this list definition maintains your customizations.
Consider making a few more changes to each of your customized Windows SharePoint Services 2.0 list definitions to make them work in Windows SharePoint Services 3.0.
All SharePoint form and list view pages now use standardized ASPX pages. Rather than each page having, for example, its own AllItems.aspx, EditForm.aspx, DisplayForm.aspx, or NewForm.aspx file, the pages now share by default a standard ASPX file. To use these standardized form pages, specify SetupPath="pages\form.aspx" in all the <Form> tags of your Windows SharePoint Services 2.0 list definitions, and specify SetupPath="pages\viewpage.aspx" in views that have pages behind them. Of course, if you customized pages for specific lists, you can continue to use them, although you must follow the guidance provided previously about upgrading .ASPX pages for use in Windows SharePoint Services 3.0.
List forms now use ASP.NET user control-based templates rather than Collaborative Application Markup Language (CAML). The CAML form definition is no longer necessary and can therefore be removed. If you wish to use a custom template for your list definition, specify Template="TEMPLATENAME" in the <Form> tag of your Schema.xml file. For more information on custom form templates, see Creating Custom Form Templates.
Consider adapting customized list definitions to use content types and shared field definitions. To do this, define new content types and shared fields in a separate site collection–scoped Feature. To upgrade your list definition, use the <ContentTypes> tag to declare which content types to implement in lists created through the definition, and annotate <Field> tags by specifying the GUIDs identifying shared fields that they must use. Note, however, that even if you use content types, your list definitions still need to declare all fields within the Schema.xml file of the list Feature.