Backward Compatibility of SharePoint 2010 Object Model on migration

Destin joy
13y
9.5k
0
0

Article

This article provides guidance to help you to conquer challenges that you might encounter as you redeploy, test, and debug your Windows SharePoint Services 3.0 and Office SharePoint Server 2007 code in SharePoint Foundation 2010 and Microsoft SharePoint Server 2010, respectively. Microsoft SharePoint Foundation 2010 and Microsoft SharePoint Server 2010 contain object model upgrades but that is compatible with existing solutions developed for Windows SharePoint Services 3.0 and Microsoft Office SharePoint Server 2007. But some namespaces, classes, and methods are now outdated. Any way they are still available and will continue to work as expected. We can synchronize customizations and applications with the upgraded versions of SharePoint 2010 once we have redeployed them.

We have to rewrite and recompile the code that refers to files in "12" hive folder. You have to redeploy the files from 12 hive folder to "14" folder. Because any reference that are made to dlls or resources under the 12 folders won't work with 14 folder structure. You have to recompile custom code written for Windows SharePoint Services 3.0 and Office SharePoint Server 2007 that does not run on IIS . You should recompile custom code written for Office SharePoint Server 2007 if your solution includes a feature receiver that implements the FeatureInstalled, FeatureUninstalling, FeatureActivated, or FeatureDeactivating methods and you are deploying by using either the Stsadm command-line tool or the timer service.

We can look at some of the custom solution files that we need to move in to SharePoint 2010.

Solution Packages (.WSP Files)

Please make sure you deploy your custom solutions by using solution packages (.wsp files), because this is the best way to ensure that all of your custom files are deployed to the correct locations. But before you deploy a wsp file make sure you don't have any reference to 12 hive folder. This is the changes to the 14 folder.

Windows Installer Files

If you deploy your custom solutions using Windows Installer (.msi) packages, ensure that you change them so that your custom files are deployed to their correct locations in the "14" folder, especially if you are deploying files to locations other than the TEMPLATE\FEATURES folder. Here you don't have to recompile the files if you don't have files referencing the 12 hive.

Site Template Redeployment

Site templates are condemned. If you need to redeploy a site template to either SharePoint 2010 follow the steps below.

Create a site from the site template.
Install SharePoint Foundation 2010 or SharePoint Server 2010 on your existing server farm or on a new server farm. If you install the upgrades on a new server farm, attach the content database that contains the site that you created to the new farm.
On the new installation, on the Site Settings page, select Save Site as Template. This creates a solution package with a .wsp file name extension.

Obsolete Classes and Namespaces

Because the changes to the API in the upgrades are backward compatible, we don't have to make any changes to 2007 custom solutions before you redeploy them to the 2010 version of SharePoint0. Some classes and namespaces are obsolete, but they will continue to work as expected. If you want to start upgrading your applications so that they use the most current classes and methods, recompile your code. The compiler warnings will tell you which elements of the object model are obsolete, and which newer alternatives you should use. Figure 3 shows an example compiler warning and the corresponding mouse-over warning in Visual Studio 2010.

Event handler

You need to recompile and redeploy it.

Master page and Themes

2007 themes no longer exist in SharePoint 2010 so any customizations and design work that you have done with themes will not be imported into the new version.