SharePoint Programming

Some Important things about SharePoint 2010 Object model and its backward compatibility.

Microsoft SharePoint Foundation 2010 and Microsoft SharePoint Server 2010 contain object model upgrades that are designed to be compatible with existing solutions developed for Windows SharePoint Services 3.0 and Microsoft Office SharePoint Server 2007. Some namespaces, classes, and methods are now obsolete, but they are still available and will continue to work as expected in your custom code.

You can synchronize your customizations and applications with the upgraded versions of Microsoft SharePoint Foundation 2010 and Microsoft SharePoint Server 2010 after you have redeployed them.

The object model contains many changes and enhancements, but your custom code will still compile and, with one potential exception, it will run as expected. If in case, any of your customizations rely on list queries that can generate result sets in excess of 5,000 items or that scan all rows of lists that consist of more than 5,000 items, you must change the query size threshold.(See Later in the Post)..

Note: You must Re-compile or re-write your code in below conditions:

* You should rewrite and recompile any code that refers to files and resources in "12" hive.For example, if you have redeployed all of your files into the "14" folder and emptied your "12" folder, any references to files under the "12" folder will not work. You will need to rewrite your code to refer the files in "14 Hive" instead of "12 Hive" to make it work.

* You must recompile custom code written for Windows SharePoint Services 3.0 and Office SharePoint Server 2007 that does not run on IIS (such as console applications and services).

* 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.


Lets Look at some of the custom solutions that you would be moving to SharePoint 2010.


Moving Using Solution Packages (.wsp Files)

You can simply deploy them as we did in SharePoint 2007. You dont need to recompile them(unless, your code has references to 12 hive). If however, you want to start upgrading your applications so that they use the most current classes and methods, you should recompile your code. The compiler warnings will tell you which elements of the object model are obsolete, and which newer alternatives you should use.


Moving Using Windows Installer Files

If you deploy your custom solutions by using Windows Installer (.msi) packages, be sure to change them so that your custom files are deployed to their correct locations in the "14" folder. This is especially true if you are deploying files to locations other than the TEMPLATE\FEATURES folder.


Moving Site templates

Site templates are deprecated. If you need to redeploy a site template to either SharePoint Foundation 2010 or SharePoint Server 2010, follow these steps:

1. Create a site from the site template.

2. 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.

3. On the new installation, choose Save Site as Template from the Site Settings page. This creates a solution package with a .wsp file name extension.


CSS Changes :

When you upgrade to either SharePoint Foundation 2010 or SharePoint Server 2010, you are able to choose either backward compatibility mode or the upgraded user interface. You can however, switch between backward compatibility mode and the new interface at the site-collection level or site level.

Since, the UI has changed significantly in both SharePoint Foundation 2010 and SharePoint Server 2010, any customizations(made to SharePoint 2007 CSS) that rely on specific CSS classes and UI elements will work only in backward compatibility mode.

A property SPWeb.UIVersion is also available for developers, to programmatically get or set the UI version (3 for backward compatibility mode and 4 for the new interface).


Themes:

Themes no longer exist in SharePoint Foundation 2010 and SharePoint Server 2010, so any customizations and design work that you have done with themes will not be imported into the new interface.


Custom Actions and Toolbar Additions:

Most custom actions, including those targeted at links and edit control block (ECB) menus, continue to work as expected in the upgraded interface. Because the toolbar is replaced by the ribbon, most custom actions that add buttons to a toolbar will be
placed in the Custom Commands tab of the ribbon.

Note : Any Custom Action Element that uses the ControlAssembly attribute, the ControlClass attribute, or the ControlSrc attribute, however, will not appear in the new interface.


Site definition :

Migrate sites to a supported, predefined site definition, then apply custom features by using solution deployment.

You can also continue to use a custom site definition. You do not have to create a new site definition based on SharePoint Server 2010.

Event handler : Rewrite and redeploy as a feature.


JavaScript : In some cases, you might have to adjust the scripts to work with the new page model. Verify that it works on an upgraded site, and in both Visual Upgrade modes.


Conclusion:

Because the changes to the API in the upgrades are backward compatible, you should not have to make any changes to your custom code before you redeploy it in either SharePoint Foundation 2010 or SharePoint Server 2010. All deprecated elements of the API continue to be available to you, so that you have time to review the newer elements of the API before incorporating them into your customizations.

Also See :

Upgrading Sharepoint 2007 Customizations to SharePoint 2010