Upgrading a Custom Windows SharePoint Services 2.0 Site Definition
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.
In Windows SharePoint Services 2.0, many types of customization required customizing site definitions, which usually involved copying the STS site definition and modifying list schemas, pages, and other structural elements in the copied definition. Large parts of the custom site definition were not customized, which meant that they maintained many of the same basic traits as the STS site definition.
The way to obtain a Windows SharePoint Services 3.0 equivalent for a custom site definition in Windows SharePoint Services 2.0 varies depending on the site definition. If you did not heavily customize the site definition in relation to the Windows SharePoint Services 2.0 site definition on which it was based, the best option may be to create a Windows SharePoint Services 3.0 equivalent for that site definition and retrofit the new definition to include Windows SharePoint Services 2.0 customizations. For example, if your only customization to a Windows SharePoint Services 2.0 site definition was to add a custom list, or to copy the STS site definition and customize the Default.aspx page for a custom look and feel, then you should probably use the Windows SharePoint Services 3.0STS site definition as the base for a new custom site definition. If your customizations were more extensive, however, it would probably be better to convert the Windows SharePoint Services 2.0 site definition into a Windows SharePoint Services 3.0 equivalent. The remainder of this topic provides guidance on how to convert a customized Windows SharePoint Services 2.0 site definition into a correct Windows SharePoint Services 3.0 site definition.
Updating ASPX Pages
Because Windows SharePoint Services is deeply integrated with ASP.NET 2.0, the structure of ASP.NET pages (.aspx files) used in SharePoint sites has changed significantly. When hosting a Web site based on a Windows SharePoint Services 2.0 site definition, Windows SharePoint Services executes pages in a compatibility mode to ensure that they function within the deployment. However, when running pages from a Windows SharePoint Services 3.0 site definition, Windows SharePoint Services does not run the pages in compatibility mode for performance reasons. For this reason, when you create your Windows SharePoint Services 3.0 site definition, you must modify your ASP.NET pages to some extent.
If you have not customized ASPX pages in your Windows SharePoint Services 2.0 site definition, it is good practice to copy the Default.aspx page of the Windows SharePoint Services 3.0STS site definition (located at 12\TEMPLATE\SiteTemplates\sts\xml) into your site definition.
All Web Part pages must now contain an ASP.NET Web Part manager to function properly. Consequently, if you have customized ASPX pages, you must add a Web Part manager to them, which you do by inserting <WebPartPages:SPWebPartManager id="m" runat="Server" /> into the pages.
Note
Because all SharePoint master pages include a Web Part manager, it is good practice to take the extra step of basing your ASP.NET pages on a master page. You gain more flexibility from a master page-based infrastructure, and master pages help ensure that common parts of Windows SharePoint Services functionality are included on the page. For more information, see Master Pages.
Editing Onet.xml
The structure of the Onet.xml file has changed in fundamental ways. If you did not customize Onet.xml in your Windows SharePoint Services 2.0 custom site definition, it is good practice to copy the Windows SharePoint Services 3.0 Onet.xml from 12\TEMPLATE\SiteTemplates\sts\xml into your site definition.
In Windows SharePoint Services 3.0, all XML files in the setup directory have been converted to use resource expressions ($Resources) to make them work for any language whose language packs have been installed. To make a Windows SharePoint Services 2.0 site definition work for multiple languages, and to benefit from this expanded use of resources, you must make numerous changes in the Windows SharePoint Services 2.0 XML files. In this case, it may be best to copy the Windows SharePoint Services 3.0STS site definition and add your customizations to it.
If you customized the Onet.xml file in your Windows SharePoint Services 2.0 site definition, you must modify the file to work in Windows SharePoint Services 3.0. The following basic steps can help make your Windows SharePoint Services 2.0 Onet.xml file more consistent with a Windows SharePoint Services 3.0 site definition.
To ensure that Web sites created through your definition consistently use the new Windows SharePoint Services 3.0 base list types, remove the <BaseTypes> section from your Windows SharePoint Services 2.0 Onet.xml file. Base list types are now included by default in SharePoint sites and do not need to be defined in your file.
Remove standard lists from the Windows SharePoint Services 2.0 Onet.xml file. Many lists required for SharePoint functionality are now included by default in Windows SharePoint Services 3.0 and do not need to be defined in your Onet.xml file. For more information, see Upgrading Standard List Definitions.
Remove the <ListTemplate> tag for lists where the Name attribute equals webtemp, listtemp, wplib, or datasrcs. Also remove the underlying list definitions for these lists by removing the LISTS\WEBTEMP, LISTS\LISTTEMP, LISTS\wplib, and LISTS\DATASRCs folders. Remove each <List> tag from the Configurations section where the Type attribute equals 113 (Web template gallery), 114 (list template gallery), or 111 (Web Part gallery).
Consider mapping the DocumentTemplates section to Windows SharePoint Services 3.0 document templates. The system of expressing document templates in a site definition has not changed significantly in Windows SharePoint Services 3.0. Document templates are still stored in a per-locale directory.
For your specific site definition you must ensure that you have the corresponding set of document template files in \12\TEMPLATE\<locale ID>\<site definition name>. However, if your document template files are not customized, it is possible to simply make your site definition re-use document templates. To do this, annotate each <DocumentTemplate> node in your Onet.xml file to specify Path="STS".
Final Considerations
After you have customized your site definition, test it in Windows SharePoint Services 3.0 to ensure that new Web sites created through the definition function as expected. After you have created the proper Windows SharePoint Services 3.0 site definition, the next step is to create an upgrade definition to map your site definition from Windows SharePoint Services 2.0 to Windows SharePoint Services 3.0.