How to Redeploy Existing Apps in SharePoint Server 2010

Introduction

The object model enhancement of Microsoft SharePoint Foundation 2010 and Microsoft SharePoint Server 2010 has incorporated excellent features to handle compatibility issues. Solutions developed in Windows SharePoint Services 3.0 and Microsoft Office SharePoint Server 2007 can be upgraded to the present standard by using the VSeWSS upgrade tool.  

Import VSeWSS to Visual Studio 2010

This can be used to convert existing Visual Studio extensions for Windows SharePoint Services solution packages (written either in Microsoft Visual Basic or Microsoft Visual C#) into Microsoft Visual Studio 2010 solutions.

After this tool is run, Visual Studio 2010 Packaging Explorer opens up and shows a list of available items in the package, which may added in the item solution. It is a pretty straight forward method thanks to the provision made by Microsoft in Visual Studio 2010 IDE.

Visual Studio 2010 Packaging Explorer

After the conversion this new solution needs to be redeployed to the updated framework.

Upgrading a Customized Solution

An existing solution can be upgraded in two places.

In either case, it is best to use SharePoint solution package (.wsp) rather than the Windows Installer (.msi) package for redeployments. One convincing reason is that it is the best way to ensure that all of your custom files are deployed to the correct locations. Deploying Windows Installer (.msi) packages, has the disadvantage that one has to specifically ensure that the changes effect the correct locations, especially when deploying files to locations other than the TEMPLATE\FEATURES folder. Site templates are deprecated. However, if one needs to redeploy a site template to SharePoint Foundation 2010 or SharePoint Server 2010 one has to:

Upgrading with the 2010 Object Model

The object model has gone through numerous enhancements in comparison to its previous model.  Old codes compile with exceptions,  yet queries that generate a large volume of data, such as generating result sets in excess of 5000 items or that scanned a list containing more than 5000 items, will need their query size threshold changed.  Otherwise one can apply alternative approaches by choosing appropriate measures from the changes incorporated in the object model’s new element.

The changes in the API are backward compatible so enhancement to newer versions require minimal changes. Though there are classes and namespaces in the newer version termed as obsolete, they work as expected only with the caution of deprecation. However, it is a best practice to remove deprecation and replace with the suitable changes from the newer version to be on the safe side; deprecated types or methods or properties are eventually going to be removed.

Note: Be sure to check Microsoft SharePoint Server 2010: New, Removed, and Obsolete Types and Methods   for deprecated types and methods in Microsoft SharePoint 2010 object model.

Throttling Large List

The default query threshold of Microsoft SharePoint Foundation 2010 and Microsoft SharePoint Server 2010 is 5,000 items. Custom code working with a query result exceeding that limit will have performance issues and will fail. There are provisions to override this limit. To increase this threshold or to enable the object model to override the threshold:

Setting the query size threshold

Changing User Interface

There is a significant change in UI in both SharePoint Foundation 2010 and SharePoint Server 2010. So while upgrading one is able to choose either the old or the upgraded user interface. One may switch between old user interface and Visual Upgrade at the site-collection level or site level:

• Use PSConfig and PSConfigUI to preserve existing site’s look and feel.
• Use Windows PowerShell cmdlet Mount-SPContentDatabase to preserve existing site’s look and feel while upgrading by attaching old content.

A web interface may also be used to set all sites in a site collection to the upgraded UI. This  prevents the user from using the older interface.

To set all sites in a site collection to the upgraded UI, click Site Collection Administration from Site Settings and then click Supported User Experiences.

Changing the UI at the Site-collection Level

Changing the UI at the site-collection level

SPWeb.UIVersion property may be used to programmatically get or set the UI version.

UIVersion property is available for:

The following examples show how to implement these controls in your .aspx files.

XML

<SharePoint:VersionedPlaceHolder ID="vph4" runat="server" UIVersion="4">
   <div>Content</div>
</SharePoint:VersionedPlaceHolder>
 

XML

<SharePoint:UIVersionedContent ID="vc4" runat="server" UIVersion="4">
<ContentTemplate>
<div>Content</div>
</ContentTemplate>
<SharePoint:UIVersionedContent> 

By setting SPWeb.UIVersionConfigurationEnabled, and SPSite.UIVersionConfigurationEnabled Boolean properties, one can enable/disable Supported User Experiences.

Conclusion

Thus without writing code one can take advantage of the enhanced features in SharePoint Foundation 2010 and SharePoint Server 2010. Rewriting code immediately is not an absolute necessity. Deprecated elements of the API continue to work as expected, and as a result developers have the time to review newer API elements before incorporating them. The provision for keeping the old user interface has an added benefit on the part of a developer to rethink the adoption of the newer UI and redesign customization to its full advantage. Moreover the adoption of the newer UI can be one at a time. Some sites may stay in the older version of the interface and other sites can immediately adopt the new. The framework provides the ability to migrate customizations and accept new capabilities methodically in stages, so that adoption can be at a pace that suits best.

TAGS:

SharePoint Server, Visual Studio