Wednesday, February 29, 2012

Hide a SharePoint list field based on user group using JQuery Webservice in 2010

A field in a SharePoint list form like NewForm.aspx or EditForm.aspx can be easily hidden by using the following Jquery statements. Assume that we have an input field named Feedback

var feedbackField = $("input[title=Feedback]");
feedbackField.parent().parent().parent().hide();   
But what if we want to hide the field for a particular SharePoint user group only. Let's say we have a user group named "Test Group" and we don't want to show the Feedback field to the users of this group. In order to achieve this we need to know whether the current logged in user belongs to the "Test Group" or not.This can be done by using  SPServices, a Jquery library for SharePoint web services.
Grab the latest version of SPServices Jquery library from codeplex and Jquery from here.
Once you have both .js files, upload them to a SharePoint document library. In my case I created a folder named JS inside Shared Documents Document library and uploaded both files inside it. Next Create any SharePoint list and create a Text column named Feedback in it. Now we will add a content editor webpart to the NewForm.aspx page of this list. In order to edit the NewForm.aspx page append 
?PageView=Shared&ToolPaneView=2 to the NewForm.aspx page in the url. Your url should look something like this http://ws2003/Lists/Project%20Tasks/NewForm.aspx?PageView=Shared&ToolPaneView=2. Now add a content editor webpart to the page and the following script to the content editor webpart.

<script type="text/javascript" src="/Shared%20Documents/JS/jquery.min.js"></script>
<script type="text/javascript" language="javascript" src="/Shared%20Documents/JS/jquery.SPServices-0.6.2.min.js"></script>
<script language="javascript" type="text/javascript">
$(document).ready(function() {
  $().SPServices({
    operation: "GetGroupCollectionFromUser",
    userLoginName: $().SPServices.SPGetCurrentUser(),
    async: false,
       completefunc: function (xData, Status) {
       var xml = xData.responseXML.xml;
       if (xml.search('Test Group') != -1)
{
        var feedbackField = $("input[title=Feedback]");
        feedbackField.parent().parent().parent().hide();       
}
     }
  });
});

Thursday, February 16, 2012

How to create custom properties for visual webpart in SharePoint 2010


In this article we will be seeing how to create custom properties for visual webpart in SharePoint 2010.

Steps Involved:

  • Open Visual Studio 2010.
  • Create an "Empty SharePoint Project".
  • Right click on the solution and click on Add => New Item.
  • Select "Visual Web Part" template from SharePoint 2010 installed templates.
  • Entire solution looks like the following

    share1.gif
     
  • Replace CustomPropertiesVisualWP.cs file with the following code.
    using System;using System.ComponentModel;using System.Web;using System.Web.UI;using System.Web.UI.WebControls;using System.Web.UI.WebControls.WebParts;using Microsoft.SharePoint;using Microsoft.SharePoint.WebControls;
    namespace CustomProperties.CustomPropertiesVisualWP
    {
        [ToolboxItemAttribute(false)]
        public class CustomPropertiesVisualWP :
    WebPart    {
            public static string _value;
            [System.Web.UI.WebControls.WebParts.WebBrowsable(true),
             System.Web.UI.WebControls.WebParts.WebDisplayName("Enter the Value"),
             System.Web.UI.WebControls.WebParts.WebDescription(""),
             System.Web.UI.WebControls.WebParts.Personalizable(
             System.Web.UI.WebControls.WebParts.PersonalizationScope.Shared),
             System.ComponentModel.Category("anavijai Custom Properties"),|
             System.ComponentModel.DefaultValue("")]
            public string _Value
            {
                get { return _value; }
                set { _value = value; }
            }
            // Visual Studio might automatically update this path when you change the Visual Web Part project item.        private const string _ascxPath = @"~/_CONTROLTEMPLATES/CustomProperties/CustomPropertiesVisualWP/CustomPropertiesVisualWPUserControl.ascx";
            protected override void CreateChildControls()
            {
                Control control = Page.LoadControl(_ascxPath);
                Controls.Add(control);
            }
        }
    }

  • In CustomPropertiesVisualWPUserControl.ascx I have added one label "lblResult" and button "btnClick".
  • Replace CustomPropertiesVisualWPUserControl.ascx.cs with the following code.
    using System;using System.Web.UI;using System.Web.UI.WebControls;using System.Web.UI.WebControls.WebParts;using System.ComponentModel;
    namespace CustomProperties.CustomPropertiesVisualWP
    {
        public partial class CustomPropertiesVisualWPUserControl :
    UserControl    {
            protected void Page_Load(object sender, EventArgs e)
            {
            }
            protected void btnClick_Click(object sender, EventArgs e)
            {
                lblResult.Text = CustomPropertiesVisualWP._value;
            }
        }
    }

     
  • Build and deploy the solution.
     
  • Go to the SharePoint Site =>Site Actions =>Edit Page =>Editing Tools => Insert =>Web Part =>Categories => Custom =>Select CustomPropertiesVisualWP.
     
  • Click on Add.
     
  • The web part looks like the following with a button.

    share2.gif
     
  • Edit the webpart you could see a new custom category in the webpart properties.

    share3.gif

     
  • Enter the value and click on Ok.

    share4.gif
     
  • In the CustomPropertiesWP click on the button.

    share5.gif

Wednesday, February 15, 2012

SharePoint 2010 : Migrate User Controls to SharePoint 2010

SharePoint Overview


SharePoint is a very robust and scalable Content Management and Collaboration Platform from Microsoft. It extends over the existing ASP.NET framework and provides a whole set of out of the box features for setting up well integrated websites in minutes, without any development knowledge. The soul of SharePoint is Web Parts and all users interact with the site through web parts placed into pages. There are numerous out of the box web parts that let users access the site and its features.


However, at times the out of the box functionality is not sufficient or is not customizable to the degree that one requires. Thus it becomes inevitable to build our own web parts that provide the necessary functionality.


A web part is a reusable component that can be added into any SharePoint page in any site and can be configured to perform its functions through its properties. Example of web parts could be a Slide Show Web part that displays a slide show of images in an Image Gallery in SharePoint, or a component that displays the weather whose location can be configured via a property or a stock ticker or a twitter feed web part etc.


Such web parts can be built using the ASP.NET Web Part Framework or by using the extended SharePoint Web Part framework. There are various advantages of using either method but at a beginner level, the differences are minor and hence are not discussed further here and we will build a plain vanilla ASP.NET Web Part in this article.


Microsoft has recently launched a new version of SharePoint called SharePoint 2010. The earlier version of SharePoint was SharePoint 2007 which is in use in most production systems today.  There are basically two flavors of SharePoint.
      •   Windows SharePoint Services  (WSS) 3.0 / SharePoint Foundation 2010
      •   Microsoft Office SharePoint Server (MOSS) 2007 / SharePoint Server 2010


WSS 3.0 is part of the SharePoint 2007 suite and the SharePoint Foundation 2010 is part of the SharePoint 2010 suite. Both are free with Windows Server and Microsoft has heard the developer’s call and made SharePoint 2010 installable on client operating systems such as Windows Vista and Windows 7 for development purposes only. However WSS 3.0 or MOSS 2007 were not installable on Vista or Win7 (sans a hack provided by Bamboo solutions.). These are stable versions of SharePoint but are more suited to smaller organizations with lower requirements.


The full version of SharePoint is MOSS 2007 of the SharePoint 2007 suite and SharePoint Server 2010 of the SharePoint 2010 suite. These are highly scalable and robust systems with support for many thousands of users and hundreds of Terabytes of data plus a host of Search, Business Intelligence and other products that make it all the more worthwhile for a large Enterprise to invest in this costly product.
SharePoint 2010 boasts of a host of new features and enhancements over its successor, SharePoint 2007. The exhaustive list of new features is beyond the scope of this article.


For the purview of the article we will build a sample ASP.NET 2.0 web part using User Controls that can be deployed to any of these versions of SharePoint. A web part can be deployed to SharePoint directly from Visual Studio but in most real world cases, it is packaged into what is called the Solution package or WSP that can be deployed and re-user in any SharePoint site.


“A WSP file is basically a .CAB file with an extension of .WSP which contains all the necessary resources that will deploy a web part or feature to a SharePoint server, including directives for entries to Web.config files and paths to which to deploy files and binaries to. Creating a WSP file manually is a cumbersome and error prone process and more automated mechanisms are usually sought after in most real world projects. Developers can install the Visual Studio Extensions for WSS (VSeWSS) which provides Project Templates for Web Parts, Site Definitions and List Definitions. Another 3rd party component which is more popular for creating WSPs is the WSPBuilder project which is a free add-on for Visual Studio and will create and deploy WSPs for us without having to create or tweak any XML or DDF files by hand. Familiarity with using the WSPBuilder is a must for any SharePoint developer at this point in time.”


A common method to develop web parts that has gained favor with developers and is also well recommended is to create ASP.NET Web User Controls and load them into a Web Part in code.


There a few pros and cons of this method which are detailed below:

Pros:

•   Visual Support: User Controls can be visually designed in the Visual Studio Design editor and thus are much better to render visually than adding web controls in code behind.
•   Reusability: You may have existing ASP.NET User Controls which you want to deploy to your SharePoint site. Or you might want to use the same control in an ASP.NET site and a SharePoint site, for example a Chart control. Anyway, they are easily portable and easy to deploy where ever you need them.
•   Developer Familiarity: Often this is an assumed or unrealized factor in most organizations but having to ramp up developers to newer technologies is a very costly affair. ASP.NET Web User Controls have been in existence since inception of ASP.NET and most developers are familiar with them (or should be).
•   Debugging Friendly: User Controls can be tested and debugged in an isolated shell and not necessarily deployed to SharePoint every time a line of code is changed.

Cons:

•   Performance: Although most implementations of SharePoint would not bother about the performance of loading a user control dynamically in a web part, there are few scenarios where architects would have questions about the performance of this method, especially in large installations and for a web part that is present in every single page in the site like a World Clock etc.
•   Packaging: Although packaging a web part is no child’s play without the use of a tool like WSPBuilder, there is one scenario where User Controls have a deployment difficulty when using a 3rd party component called the SmartPart.


“ The SmartPart is a free open source Web Part Feature for SharePoint which allows us to pick a User Control from the browser at run time. All the developer has to do is to place his User Controls (and the Code Behind files too!) into a folder inside the Site’s virtual directory and SmartPart will pick it up.  Makes developing with User Controls all the more simple. No command lines, no deployment of features et. al.  However, WSPBuilder in its current version does not support deploying files to custom virtual directories (other than 80) and there are documented ways to overcome this hurdle. ”

In Conclusion, using the SmartPart directly or by extending it as per your needs is usually common place in most SharePoint implementations. However, in this article, we will discuss how to create our own User Control container Web Part.



In SharePoint 2007,



In SharePoint 2007, one had to create a web part to load and use a user control. This was a well accepted method but had packaging and deployment difficulties in having to maintain a base web part class and a separate user control class and maintain different or single assemblies (DLL’s) for each of them.

In SharePoint 2010, 




Visual Studio now supports a new type of Item Template for SharePoint 2010 called the Visual Web Part that provides all the packaging and deployment plumbing and allows the developer to visually design the web part using a User Control, add business logic and code to it and package and deploy it directly without having to manually create and manage a container web part class.


In this section, we will build a sample project for both SharePoint 2007 and SharePoint 2010 that loads a simple form to collect user information and display it in a stylized visiting card.
For the SharePoint 2007 project, we will use the most common tools for building the web part – Visual Studio 2008 and VSeWSS 3.0, v1.3 Mar 2009 CTP.
For the SharePoint 2010 project, we will use the new Visual Studio 2010 and demonstrate the Visual Web Part template type.

Visiting Card Generator - Sample Project


SharePoint 2007 Sample Project

Download and install the WSPBuilder Extensions for Visual Studio 2008.

1.   In Visual Studio 2008, create a new project. Select your language (C#) and select WSPBuilder under it. Select the WSPBuilder Project template, specify the project path and name and click OK.




2.   WSPBuilder will create a 12 folder for us. The 12 folder represents the SharePoint root folder.




“The SharePoint Root folder for SharePoint 2007 is at the following path:
C:\Program Files\Common Files\Microsoft Shared\web server extensions\12

The User Controls are stored at the following path by default:
C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\CONTROLTEMPLATES.“

3.   Add the folders as shown below.




4.   Under the CONTROLTEMPLATES\UserControlWebPart folder, add a New Item and select Web User Control. Name it VisitingCard.ascx.




If you don’t see Web User Control in the Add New Item dialog, don’t be alarmed. By default (and strangely), the WSPBuilder project is not of the ASP.NET project type that includes Web User Controls. To get around this, follow these steps:
i.   Right click on the project name in Solution Explorer and click Open Folder in Windows Explorer.
ii.   Open the UserControlWebPart.csproj in Notepad or any text editor.
iii.   Locate the key <ProjectTypeGuids> and prefix the following GUID as it is inside the tag: {349C5851-65DF-11DA-9384-00065B846F21};
iv.   Save and close Notepad and switch to Visual Studio. It should now alert you that the Project file has been modified outside the environment. Press Reload to reload the project.
v.   Now proceed normally to Add New Item and the Web User Control should be available.



5.   In Solution Explorer, right click on the Project and select Add -> New Item. In the Add New Item dialog, select WSPBuilder in the left pane and select the Web Part Feature in the right pane. Give the web part a name and click OK.



WSPBuilder will prompt you to enter a title and description for the feature. Leave these as default for now. Ensure that the Scope selected is Web meaning the feature will be deployed in the WebSite scope.

Your project structure should look like this now:




WSPBuilder will create the necessary files for a Web Part (elements.xml, .webpart file, feature.xml). It also creates a separate folder called WebPartCode and creates a class file there that will contain the code for our web part. The class file is prepopulated with some sample code.


6.   Update the @Control directive in the VisitingCard.ascx with the fully qualified path to the project’s DLL, as in the illustration below. Update the namespace in the VisitingCard.ascx.cs and VisitingCard.ascx.designer.cs appropriately.



An easy way to obtain the fully qualified name for the DLL:
i.   Open the UserControlContainerWP.webpart file.
ii.   Locate the key <type> under <metaData/>.
iii.   The 2nd half of the string value “name” (after the comma) is the fully qualified name of the DLL that this project will build. Copy and append it to the Inherits attribute in the VisitingCard.ascx’s @Control directive.





7.   The Web Part we added is our container web part where we will load our user control in code in the WebPartCode/UserControlContainerWP.cs file as shown below.



8.   We now proceed to create the controls in the User Control and add code to the code behind file for the control. This can be viewed in the sample code provided.

We will add a couple of panels – one with form fields to collect user data and another with a customized view to display the visiting card with user information. In the code behind for the User Control, we will add button click handlers to collect the data entered by the user and display them in a predefined visiting card panel.


9.   Right click on the project name in Solution Explorer and click WSPBuilder->Build WSP. WSPBuilder will build the solution and create a solution package (WSP) and save it in the project folder.



10.   Again, right click on the project in the Solution Explorer and click WSPBuilder -> Deploy. WSPBuilder will deploy the Web Part and the User Control to the 12 Hive, the DLL to the GAC and make a SafeControl entry in the web.config of all available SharePoint sites.

11.   Open your browser and navigate to your SharePoint site. Login if necessary (as a Site Collection Admin) and go to Site Actions -> Site Settings -> Site Features to show a list of Features deployed to the site. Our UserControlContainerWP must be listed here if the deployment succeeded. Click on Activate to activate the feature and make the web part available for the site.



12.   Navigate back to the Homepage of the site. Click Site Actions -> Edit Page. Once the page loads in Edit Mode, click on Add a Web Part in any Web Part Zone.
13.   Select our UserControlContainerWP from the window that pops up and click Add.



14.   Our web part is added to the page and must be visible if there are no errors. Click on Exit Edit Mode in the top right. The web part must be visible as show below.






SharePoint 2010 Visual Web Part Sample Project

Make sure that SharePoint 2010 (SharePoint Foundation 2010 or SharePoint Server 2010) is installed on the same machine that you will be developing on. In our sample, SharePoint Server 2010 is installed on a Win 7 x64 bit machine. Although Win 7 is not supported by Microsoft for SharePoint, it is accepted to install it on client machines having Vista and Win 7 for Development purposes only.

1.   Create a new project in Visual Studio 2010. Select your preferred language (C#/VB) and select SharePoint in the left pane. This displays the available VS 2010 templates for SharePoint. Select Visual Web Part and click OK.




2.   Visual Studio will now prompt you for the deployment URL and a trust level. Sandboxed solutions are a new feature of SharePoint 2010 but let’s just move on with a regular Farm Deployment solution as in the old days.




3.   VS2010 creates the Solution structure for us (screenshot above) and creates the user controls and code behind files for us, plus the necessary .webpart file and the Elements.xml which will be used for packaging and deployment.




4.   The User Control can be customized as usual by using the Visual Studio design mode by dragging and dropping controls from the Toolbox. The necessary headers and directives are already added to the User Control.




We will now proceed with the coding and design of the control. The sample code for the same is available. The code is similar to the SharePoint 2007 project.





5.   Build and deploy the web part using Visual Studio. If you had set the Deployment URL correctly in Step 2, the web part should deploy the WebPart and User Control files to their respective locations in the SharePoint root directory, the DLL to the GAC and make necessary safe control entries to the SharePoint site’s web.config file.

Note: For SharePoint 2010, the SharePoint Root will have the following path:
C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\TEMPLATE

The User Control (.ascx) file will be deployed to a folder within the CONTROLTEMPLATES folder inside the SharePoint Root. The WebPart files will be deployed to a folder within the FEATURES folder inside the SharePoint Root.

6.   Once deployment succeeds, VS will launch the site in the browser. Edit the page from the Site Actions menu and Click on Add Web Part in any Web Part Zone.
SharePoint 2010’s UI has been completely revamped to include the Office like Contextual Ribbon for selecting actions based on what is selected in the Page. (Screenshot above)
7.   Add the Web Part to the page. Ours is titled Visiting Card. Click on Save & Close to save the changes and close the Editing Toolbar.
8.   The Web Part is visible in the page and can be used as designed.







Although Jon Doe cannot expect to win many leads with that card design, for the purpose of this sample project, he will have to make some adjustments.
As can be seen from the above steps, we did not create a container Web Part to load the User Control dynamically as we did with the SharePoint 2007 Project. That is the exact advantage of using the Visual Web Part item template in Visual Studio 2010 for SharePoint 2010. Visual Studio even creates a .WSP Solution file for us to manually deploy the Web Part to any SharePoint site. The WSP file is stored in the project’s Bin folder.

Conclusion

SharePoint is a highly customizable, scalable and robust Content Management & Collaboration System that integrates well with existing systems and applications such as Active Directory and Office Applications.


In this article, we have seen the different versions and flavors of SharePoint that are available.
We discussed about a common method of developing on the SharePoint platform – through the use of Web User Controls. We detailed the Pros and Cons of using this method for development.



We have discussed in detail about the development and use of Web User Controls in SharePoint Web Parts for both versions of SharePoint – 2007 and 2010. In SharePoint 2007, one had to create a Web Part Feature and in the code for it, load the User Control and add it to the web part. This was an accepted means to develop on SharePoint 2007. This however had few rough areas that were ironed out in SharePoint 2010. SharePoint 2010 provides an Out of the Box solution to add and deploy User Controls in Web parts through the use of Visual Web Parts.
We have also seen how to use the SharePoint developer’s favorite deployment plug-in – WSPBuilder.


To conclude, developing for SharePoint using User Controls is a common method of development and is supported in all versions of SharePoint, although SharePoint 2010 provides some enhancements to this process.

User Control Architecture in SharePoint

SharePoint 2010: How to Migrate a SharePoint 2007 Site to SharePoint 2010 Using Database Attach

Change is never easy! Whether it's going to college, getting married, or just getting the new, cool haircut you've always wanted, there will be something that you'll miss not having (freedom of the single life, anyone?). Moving to SharePoint 2010 is no exception. Although upgrading is rewarding, with improvements in many areas, you will still need the precious content that exists in your current SharePoint 2007 environment. In this article, I'll demonstrate how to migrate a site to SharePoint 2010 using the database attach method.
Challenge:
How can I migrate just the site/site collection I want from SharePoint 2007 to SharePoint 2010?
Moving the entire farm to SharePoint 2010 could take a lot of time, bordering on seeming like forever. Sometimes, however, we just want to get the contents of a specific site/site collection up and running on the new platform as soon as possible.
Solutions:
Using the database attach method, we can migrate a site/site collection to SharePoint 2010 following these basic steps:
Step 1: Move the needed site to a new Web application.
Step 2: Copy the content database backup to the SharePoint 2010 SQL server.
Step 3: Mount that content database to the SharePoint 2010 server.
Notes before migrating
  • Always backup your content database just to be on the safe side.
  • The SharePoint 2007 server must have SharePoint Service Pack 2 installed.
  • Run the upgrade check program on your SharePoint 2007 server, stsadm -o preupgradecheck. Fix any issues reported before moving on to the next step.

Step 1: Move the site to a new web application in SharePoint 2007
Let's say we want to migrate the SharePoint site at http://duyfarm/TeamSite.
  1. First, create a new Web application and blank site collection (for example: http://duyfarm:6789).
  2. Login to the SharePoint server using an account that has the following rights/permissions:
    • SharePoint Farm Admin.
    • Local Administration rights on the Web server.
    • db_owner permission on the content databases.
    • Make sure the access account has access to the site content (sometimes farm admin might not be a site collection admin).
  3. Open Command Prompt and change directory to %COMMONPROGRAMFILES%\Microsoft shared\web server extensions\12\bin, then run the following STSADM commands: stsadm -o export -url <URL name> -filename <export file name> -includeusersecurity
    stsadm -o import -filename <import file name> -url <URL name> -includeusersecurity
       

The imported Web application might look like this:
         

Step 2: Copy the content database backup to the SharePoint 2010 SQL server
  1. Open Microsoft SQL Server Management Studio. Right-click on the content database and select Tasks > Backup...\

  2. Enter the Backup Name, select Destination, and click OK to start.

  3. Copy this backup file to the SharePoint 2010 SQL server.

Step 3: Mount the content database to the SharePoint 2010 server
  1. On the SharePoint 2010 server, create a new empty Web application. For example: http://duyfarm2010:6789.
  2. If you have any custom components on the original site, install them to this Web application now.
  3. After that, we can restore the SharePoint 2007 backup to SharePoint 2010 SQL Server. Open Microsoft SQL Server Management Studio. Right-click on Databases and select Restore Database...
  4. Enter the new database name, making sure that you don't overwrite the original content database. Select the Source and click OK to start.
  5. Open SharePoint 2010 Management Shell and dismount the current SP2010 content database.
    Dismount-SPContentDatabase <ContentdBName>
  6. Verify that we have all the needed custom components. If there are any errors, make sure you correct them before mounting the SP2007 content database.
    Test-SPContentDatabase -Name <DatabaseName> -WebApplication <URL>
  7. My test shows no error, so we are ready to run the Mount-SPContentDatabase cmdlet. This cmdlet also upgrades the SP2007 content to SP2010.
    Mount-SPContentDatabase <ContentDb> -WebApplication http://SiteName
  8. After this process has completed, you need to review the log files (the upgraded log file and error log file) to make sure there are no errors. The log files are located at %COMMONPROGRAMFILES%\Microsoft Shared\web server extensions\14\LOGS. The logs are named in the following format: Upgrade-YYYYMMDD-HHMMSS-SSS-error.log and Upgrade-YYYYMMDD-HHMMSS-SSS.log, where YYYYMMDD is the date and HHMMSS-SSS is the time (hours in 24-hour clock format, minutes, seconds, and milliseconds). If there are errors at this time, they will most likely be due to some customization done on the SharePoint 2007 server.

We have finally finished the migration process. Notice that after our upgrade is completed, the new site looks exactly like it was in SharePoint 2007. In SharePoint 2010, there is a feature called Visual Upgrade that gives you an option to switch between SharePoint 2007 look and feel or the SharePoint 2010 view.  Note that if you have customized themes on the old site, you must re-create the new theme on the new site before you can switch.  To switch over to the new SharePoint 2010 look, do this:          
  • Login as Site Owner and select Site Actions > Visual Upgrade.


  • Select Update the user interface. Click OK.


 Here is the SharePoint 2010 look and feel:


Notes:
See Also:

SharePoint 2010: Migrate a Single List to SharePoint 2010 from 2007

Challenge:
I recently needed to move a list from SharePoint 2007 to SharePoint 2010.  I wanted the destination list to have the exact content as the source list including structure, list items, and attached files.  Since SharePoint does not have an STSADM.EXE command line tool to accomplish this, it needs to be done manually.  What are our options?

Solution:
After doing some research, I discovered that there are a few ways to accomplish this task.  You can migrate a single list from SharePoint 2007 to SharePoint 2010 using one of four methods:
  1. Migrate a single list from SharePoint 2007 to 2010 using a list template
  2. Migrate a single list from SharePoint 2007 to 2010 using an Access table
  3. Migrate a single list from SharePoint 2007 to 2010 using the detach database method
  4. Migrate a single list from SharePoint 2007 to 20110 using PowerShell
I'll summarize and show how each of these methods works in this article.
Method 1 - Migrate a single list from SharePoint 2007 to 2010 using a list template
The first method to consider is creating a list template from SharePoint 2007 and bringing it into SharePoint 2010. But you will likely be disappointed to learn that SharePoint 2010 will not recognize this template, so you cannot create any list from that template.  A workaround for this problem is posted on Tom's Random Ranting blog, showing how you can easily modify the manifest file that gest created every time you create a template.
Tom's basic method is:
  • Extract the contents of the STP file (it's really just a CAB file)
  • Edit the manifest.xml file, changing the ProductVersion element from 3 to 4
  • Repackage the STP file
It is quick way to bring a list over, but there is one important limitation: if your source list has many items (thousands), you might not be able to copy the entire contents of the list.

Summary
So if you need to migrate list templates STP's from SharePoint 2007 to 2010, you could try the following:

  1. Rename the original .STP to .CAB
  2. Extract its manifest.xml to a local folder (lets call it {workingfolder})
  3. Search for the ProductVersion element. This should have a value of 3
  4. Change its value to 4
  5. Repackage the manifest.xml into a .CAB. I've done this by using makecab.exe in the C:\Windows\System32 folder
    Syntax
    : makecab.exe {workingfolder}\manifest.xml {workingfolder}\{template-name}.cab
  6. Change the generated cabinet's extension from .CAB back to .STP and upload it into the _catalogs/lt (Upload into list template Gallery in sharepoint 2010)

Method 2 - Migrate a single list from SharePoint 2007 to 2010 using an Access table
The second way to migrate a list from 2007 to 2010 is to use Access. Basically, you need to export a MOSS 2007 list to an Access table, and then import to SharePoint 2010:
Step 1:  Open source list with Access

Step 2: Select Export a copy of the data to a new database

Step 3: The SharePoint list will now be imported into Access.  You can add or modify columns in this mode to select what you need.


Step 4: From Access, select External Data tab in the Ribbon, and select SharePoint List in the Export section. Enter a SharePoint 2010 site address and select OK.

Your result should appear as follows:

You might be wondering if this method also works with a Document Library since the Document Library doesn't have the menu Action -> Open for Access!  Yes, of course it does, but for a Document Library, you need to use the similar "Open with Windows Explorer" menu action.
Step 1: Open both Document Libraries with Window Explorer


Step 2: Select all the documents and folders that you need, and select Copy.

Step 3: Paste the data into the destination folder.

And the result is:

Limitation
You will notice that one of the limitations of this migration method is that the Modified Date, Created Date, Modified By, and Created By columns do not retain their values from the source list.  You also need to have Microsoft's Access 2010 in order to use this method.

Method 3 - Migrate a single list from SharePoint 2007 to 2010 using the detach database method
In this method, we will try to migrate using an STSADM command that is supported by SharePoint 2007.  All we have to do is use the Export and Import command to migrate a list.
Step 1:  Migrate the entire SharePoint site that contains the list to be exported from 2007 to 2010.  Please refer to an earlier post in the Cookbook series, How to Migrate a SharePoint 2007 Site to SharePoint 2010 Using Database Attach, for the exact steps on how to do this.  You might have to create a new temporary site in SharePoint 2010 in order to migrate the site, but the site can then be removed after the desired list has been migrated.
Step 2: Once the site has been migrated to SharePoint 2010 server, let's try to move the sample Tasks list.  From Central Admin -> Backup, select Restore -> Export a site or list:

In the selection drop down box,select the list that you want to move:


At this point, you have exported the desired list to a folder on your SharePoint server, and you are now ready to import that List to the correct destination.
Step 3. Next, import the Tasks list to your final destination site.   SharePoint 2010 does not provide a User Interface in Central Admin for Granular Restore operations; therefore, you have to use PowerShell to accomplish this task:

And below is the result:


Method 4 - Migrate a single list from SharePoint 2007 to 2010 using PowerShell
Lastly, we will try to use PowerShell to Export/Import lists. We know that Microsoft has released a version of Windows PowerShell 1.0 that works with SharePoint 2007,  and which can be downloaded here.  After the installation has completed, we can write a PowerShell script to try to accomplish our goal of exporting a list.
The basic steps are:
  • Run a shell script to export a list to a DAT file
  • Change this DAT file to CAB, and extract this file so that you can access SystemData.xml in the CAB file, and modify version information there.
  • Remake the CAB file and change the extension to .CMP.
  • Use PowerShell in SharePoint 2010 to import the list from the .CMP file.
Step 1: Launch PowerShell and load SharePoint assemblies to the program.  Refer to this blog post by Nick Grattan in order to prepare your PowerShell for SharePoint 2007: http://nickgrattan.wordpress.com/2007/09/03/preparing-powershell-for-sharepoint-and-moss-2007/:

Let's write a script to export a SharePoint 2007 List. I will follow an example from Kashish Sukhija's Blog here: http://blogs.sharepointdevelopers.info/2010/05/sharepoint-2010-deployment-using.html.
[System.Reflection.Assembly]::Load("Microsoft.SharePoint, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c") 
[System.Reflection.Assembly]::Load("Microsoft.SharePoint.Portal, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c") 
$spsite=[Microsoft.SharePoint.SPSite] ("http://cleanmoss/test")
$spweb=$spsite.OpenWeb()
$openList=$spweb.Lists["Tasks"]
$exportObject = New-Object Microsoft.SharePoint.Deployment.SPExportObject
$exportObject.Type = [Microsoft.SharePoint.Deployment.SPDeploymentObjectType]::List
$exportObject.IncludeDescendants = [Microsoft.SharePoint.Deployment.SPIncludeDescendants]::All
$settings = New-Object Microsoft.SharePoint.Deployment.SPExportSettings
$settings.ExportMethod = [Microsoft.SharePoint.Deployment.SPExportMethodType]::ExportAll
$versions = [Microsoft.SharePoint.Deployment.SPIncludeVersions]::All
$settings.IncludeVersions = $versions
$settings.IncludeSecurity = [Microsoft.SharePoint.Deployment.SPIncludeSecurity]::All
$settings.OverwriteExistingDataFile = 1
$settings.SiteUrl = $spweb.Url
$exportObject.Id = $openList.ID
$settings.FileLocation = "C:\Temp\BackupRestoreTemp\"ExportList-"+ $openList.ID.ToString() +".DAT"
$settings.BaseFileName = "
$settings.FileCompression = 1
$settings.ExportObjects.Add($exportObject)
$export = New-Object Microsoft.SharePoint.Deployment.SPExport($settings)
$export.Run()
 

After you have run this shell script you will have your export list in the c:\temp\BackupRestoreTemp\ folder.
Step 2:  Next, all we have to do is change this DAT file to CAB, extract the file so that you can access SystemData.xml in the CAB file, and modify the version information there. Open the SystemData.xml file in a text editor, and change Version="12.0.0.0" to Version="14.0.0.0", and Build="12.0.0.6514" to Version="14.0.4762.1000".
Step 3:  You will have to create a new CAB file again after making the changes above.  Here is a reference showing how to make a CAB file using the Makecab.exe command: http://msdn.microsoft.com/en-us/library/dd583149(office.11).aspx.  This is sample content to create the CAB:
.OPTION EXPLICIT     ; Generate errors 
.Set CabinetNameTemplate=ListTasks.cab       
.set DiskDirectoryTemplate=CDROM ; All cabinets go in a single
.Set CompressionType=MSZIP;** All files are compressed in cabinet files
.Set UniqueFiles="OFF"
.Set Cabinet=on
.Set DiskDirectory1=ListTasks.CAB
 
; Include all files need to be presented in Cab.
manifest.xml
ExportSettings.xml
Requirements.xml
RootObjectMap.xml
SystemData.xml
UserGroup.xml
ViewFormsList.xml
00000000.dat
00000001.dat
00000002.dat
00000003.dat
00000004.dat
00000005.dat
00000006.dat
00000007.dat
00000008.dat
00000009.dat
0000000A.dat
0000000B.dat
0000000C.dat

Step 4: Finally, we can use PowerShell on SharePoint 2010 server and run the Import-spweb to import the list.

Result:

In summary, if you have a need to just import a SharePoint list from an existing SharePoint 2007 farm to a SharePoint 2010 farm, there are several ways to accomplish this task.  Which method you should use will depend on the tools that you have available, and your familiarity with each of them.  Note: There are also third-party tools available to help you with migrating sites and content in SharePoint and, for list migration specifically, you may wish to look at Bamboo's own List Bulk Import product.

Notes:
  • Using the last two methods described, we will be able to retain the original values of Modified Date, Created Date, Created By, and Modified By from the source list. Make sure to specify the parameter -IncludeUserSecurity in your import command.
  • Most of the steps we have shown in this article will require you to have Farm administration rights in order to run the necessary import and export commands.
  • If your source list contains any custom columns, you might have to install that feature on the destination SharePoint 2010 farm before doing the migration.

See Also: