Hands-On Lab
Lab: Upgrading a VSeWSS Project to Visual
Studio 2010
Lab version: 1.0.0
Last updated: 12/6/2011
CONTENTS
No table of contents entries found.
Overview
Lab Time: 45 minutes
Lab Folder: C:\Student\Labs\xx_UpgradeVseWSSSolutions
Lab Overview: In this lab exercise you will upgrade a SharePoint 2007 solution that was created using
VSeWSS 1.3 to SharePoint 2010 and the new SharePoint Tools in Visual Studio 2010. You will first import
the VSeWSS project into Visual Studio 2010 using a special project template. Importing the project
maintains artifact layout, project settings and source code. Next you will address any inconsistencies
resulting from the import.
Lab Setup Requirements
Before you begin this lab, you must run the batch file named SetupLabXX.bat. This batch file runs a
PowerShell script which creates a new SharePoint site collection at the location
http://intranet.contoso.com/sites/LabXX. You must also run the
VSeWSS_Upgrade_Sample_Beta_20100108.msi file located in the Lab Folder >> Starter Files Folder.
Accept all default choices for the installation. This installs the installer files to C:\Program Files
(x86)\Microsoft\VSeWSS Upgrade\. Navigate to this location and run the
VSeWSSUpgrade_Beta2_20091203.msi file accepting all defaults. When this is finished you must
navigate to Start menu >> All Files >> Microsoft Visual Studio 2010 >> Visual Studio Tools and right-
click on the Visual Studio Command Prompt and select Run as administrator. On the Visual Studio
Command Prompt you must run the following command DEVENV /installvstemplates ; this installs
the required project templates into Visual Studio 2010 to allow for the upgrade of VSeWSS projects
from SharePoint 2007 to SharePoint 2010.
Exercise 1: Review the Sample Project
In the XX_UpgradingVSeWSSSolutions lab folder >> Starter Files folder you will find a VSeWSS project
(ProjectManagement) containing some of the typical elements that are created when developing
SharePoint solutions. Before upgrading the solution to Visual Studio 2010 and SharePoint 2010 you will
review the contents of the project.
Review the following image which shows the sample solution activated within a SharePoint 2007 site
collection.
The VSeWSS project contains two features. The first is targeted to the site collection and the second
feature to the site. The features consist of both declarative artifacts and code. The VSeWSS project has
various project-level settings applied such as conditional compilation constants (the DEBUG flag). At the
site collection level a new 'Project' content type is provisioned together with a Web Part. The Web Part
uses CAML queries to locate projects in specific lists. The site level feature provisions a list template that
is bound to the Project content type and the feature also creates two list instances with some sample
data. The Web Part follows the Visual Web Part development paradigm, loading a User Control from the
_controltemplates folder using the Page.LoadControl method.
Exercise 2: Importing the VSeWSS
project into Visual Studio 2010
In this exercise you will import a VSeWSS 1.3 project into Visual Studio 2010. You will then review some
of the changes that were automatically applied to the source code by the import wizard. You will also
resolve a small issue that occurs during the import process.
1. Using the Windows Explorer navigate to the lab folder.
2. Navigate to the Starter Files folder and inside of this the ProjectManagement folder and then
into the ProjectLocatorWebPart subfolder. Open the ProjectLocatorWebPart.webpart file in
Visual Studio 2010.
3. Examine the contents of the ProjectLocatorWebPart.webpart file. Take note of how the Web
Part class name (i.e. type name) is defined using a GUID that is replaced at packaging time by
VSeWSS.
4. Navigate back to the ProjectManagement folder and open the Project folder. Open the
Project.xml file which contains the ‘Project’ content type definition. Notice how the event
receiver class for this content type is also defined using a GUID token.
5. Next navigate to the Properties folder and open the Attributes.cs file. Notice how these classes
are in the VSeWSS namespace. VSeWSS generates these classes to assist in the WSP packaging
process.
6. Open Visual Studio 2010.
7. On the Start Page that appears, choose New Project in order to show the New Project dialog.
8. In the New Project dialog perform the following tasks.
a. Under Installed Templates, expand Visual C# SharePoint 2010.
b. In the right-hand pane, select the Import VSeWSS Project template.
c. In the .NET Framework version selector, choose .NET Framework 3.5.
d. For Project Name enter ProjectManagement.
Note that it is very important to name your project the same as the project you will
import. This ensures that the assembly names match in both the VSeWSS project and
the Visual Studio 2010 import result.
e. Choose OK to close the dialog and show the SharePoint Customization Wizard.
9. In the SharePoint Customization Wizard dialog that appears, choose
http://intranet.contoso.com/sites/Labxx/ as the site to debug the solution with and choose
Deploy as a sandboxed solution. Choose Next to continue the import wizard.
10. In the second page of the import wizard, Browse to the location of the VSeWSS project that you
will import. You find the VSeWSS project in the xx_UpgradingVSeWSSSolutions lab folder >>
Starter Files >> ProjectManagement folder. Select the ProjectManagement.csproj file in this
folder and click Open and then click Finish to complete the import wizard and import the
project into Visual Studio 2010.
11. Review the Error List for any issues that occurred during the import process. Notice how the
import updated some assembly references and that there is one import issue to resolve. The
choice for deploying as a sandboxed solution is not allowed because of the User Control being
deployed to the _controltemplates folder. Sandboxed solutions do not allow files to be
deployed on the file system of servers in the SharePoint farm. In order to resolve this issue you
can either re-implement the User Control as a Web Server Control, or you can instead opt to
deploy the project as a Full Trust solution.
12. In order to resolve this import issue, configure the project to be deployed as a full-trust
solution. In the Solution Explorer, locate the ProjectManagement project. Left-click the project
and navigate to the Properties window (lower right corner). In the Properties window, for
Sandboxed Solution, choose False. Dismiss the warning that appears using the Yes button.
13. In the Solution Explorer, expand the ProjectManagement project and ProjectLocatorWebPart
folder. Right-click the ProjectLocatorWebPart.webpart file and choose Open in order to view
the contents of this file. Take note of the Web Part class name (i.e. type name). Earlier VSeWSS
defined the name using a GUID that was replaced at packaging time. The import process
converted this GUID to the special token $SharePoint.Project.AssemblyFullName$.
14. In the Solution Explorer, expand the Project folder. Right-click the Project.xml file and choose
Open in order to view the contents of this file. Take note of the class name of the event
receiver. The import process also replaced this GUID with a special token,
$SharePoint.Project.AssemblyFullName$.
15. In the Solution Explorer, right-click the ProjectManagement project and choose Properties in
order to view the project settings. On the Build tab, notice how the project level settings from
the VSeWSS project have been transferred into Visual Studio 2010.
This concludes exercise 2. You have now successfully imported the VSeWSS 1.3 project into Visual
Studio 2010. You have resolved the import issue by ensuring that you deploy the project as a farm
solution and you have reviewed some of the automated changes that were made to the project files
because of the differences in the packaging model used by VSeWSS and Visual Studio 2010.
Exercise 3: Refactor the Import Result
Now that the project is imported into Visual Studio 2010 it is time to refactor some of the code and
project items. You will remove some of the generated code that was used by VSeWSS to assist in the
packaging of the solution. This code is no longer required in Visual Studio 2010. You will then refactor
the layout of SharePoint artifacts to better follow the recommended approach in Visual Studio 2010.
You will separate the site columns and content type into multiple SPIs and you will combine the User
Control with the other elements that make up the visual Web Part.
The following steps are not a technical requirement for the imported solution to function correctly. They
are performed to better align the project to the Visual Studio 2010 SharePoint project model.
1. In the Solution Explorer, expand the ProjectManagement project and the Properties folder.
Right-click the Attributes.cs file and choose Delete in order to remove this file from the project.
The code in this file was used by VSeWSS to assist in the packaging process and is no longer
needed in Visual Studio 2010.
2. In the Solution Explorer, expand the ProjecLocatorWebPart SPI, right-click the
ProjectLocatorWebPart.cs file and choose Open in order to open this code file. In the editor
that opens, locate the ProjectLocatorWebPart class. Remove the Guid attribute that is applied
to this class. This attribute was used in VSeWSS to assist in the WSP packaging process.
3. In the Solution Explorer, expand the Project SPI, right-click the ItemEventReceiver.cs file and
choose Open in order to open this code file. Locate the using statements at the top of the file.
Remove following using statement:
using VseWSS;
4. In this same file, locate the ProjectItemEventReceiver class definition. Remove the Guid
attribute and the TargetContentType attribute that are applied to this class. These attributes
were used in VSeWSS to assist in the WSP packaging process.
5. In the Solution Explorer expand the Template, CONTROLTEMPLATES and ProjectManagement
folders. Locate the ProjectLocator.ascx file. Drag the ProjectLocator.ascx file into the
ProjectLocatorWebPart SPI.
6. In the Solution Explorer, right-click the Template folder and choose Delete in order to remove
this mapped folder from the project. The folder is no longer needed since it is now empty after
moving the User Control.
7. Note that moving the User Control outside of the mapped folder does not limit your capacity to
deploy the file into the _controltemplates folder. In the Solution Explorer select
ProjectLocator.ascx (inside of the ProjectLocatorWebPart SPI) and in the Properties window
(bottom right corner), locate the Deployment Location property. Note that the user control
currently will not be deployed in the _controltemplates folder. Expand the Deployment
Location property and modify the Path into CONTROLTEMPLATES\ProjectManagement\
8. Using the Solution Explorer, expand the ProjectManagement project, expand the Project folder
and open the Project.xml file. Notice how this element definition defines both site columns and
a content type.
9. Right-click the ProjectManagement project, expand Add and choose New Item. In the dialog
that appears choose the Empty Element template that is available in the Visual C#
SharePoint 2010 group. Name the element ProjectStartDateColumn and choose Add in
order to add this item to the project.
10. Move the Field definition for the Project Start Date site column from the Project.xml file
(located inside of the Project SPI location) which contains the content type into the new empty
Elements.xml file you created in the previous step.
11. Perform steps 4 and 5 for the Project End Date column and for the Project Owner column.
Now that you have refactored some of the SharePoint artifacts to follow the new Visual Studio
2010 project layout, you need to ensure that the three new site column SPIs are deployed as
part of the site collection feature.
12. In Visual Studio 2010, on the View menu, expand Other Windows and choose Packaging
Explorer. Notice that the three new SPIs have been added to the site level feature.
13. In the Solution Explorer, locate the key in the Properties folder. You should see the
ProjectManagement.snk file, which was also used in the VSeWSS project.
14. In the Solution Explorer, right-click the ProjectManagement project and choose Properties in
order to show the properties pane for this project. In the properties pane, perform the
following tasks.
a. In the vertical tab list, select Signing.
b. Ensure that Sign the Assembly is checked.
c. Also Ensure that the Choose a strong name key file is set to the
ProjectManagement.snk key
This concludes the third exercise. You have now refactored the imported project and ensured that the
same strong name key file is used.
Exercise 4: Testing the Solution in
SharePoint 2010
In this final step you will test the solution inside SharePoint 2010.
1. In Visual Studio 2010 on the Debug menu, choose Start Debugging in order to test the solution.
Perform the following steps in the browser that appears.
2. Expand the Site Actions menu and choose More Options….
3. Choose Web Part Page and click Create for the item to add into the SharePoint site.
4. Configure the Web Part Page using the following information:
a. For Name enter ProjectManagement.
b. For Layout Template choose Full Page, Vertical.
c. For Document Library choose Site Pages.
d. Press the Create button in order to create the new Web Part page.
5. In the ProjectManagement.aspx page, perform the following steps.
a. In the Full Page Web Part Zone click on Add a Web Part.
b. In the Add a Web Part interface, for Categories, select Custom.
c. For Web Parts, select Project Locator Web Part.
d. Click the Add button in order to add the Web Part to the page.
e. On the Ribbon, select the Page tab and choose Stop Editing, in the Edit section of the
ribbon, in order to show the page in display mode.
f. Test the Web Part by searching for Contoso in the Basic Projects list.