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.