With the release date of SharePoint 2010 approaching rapidly, I decided that it was about time to make my Content By Type web part available for SharePoint 2010. In this small series, I will describe my adventures to the first release of the web part. Part zero of this series is this blog post, where I described how I configured my development environment (for usage on Windows 2008 Server R2). In this post I wrote down the steps to get to the first working prototype. The screenshot below shows the web part in SharePoint 2010.
Recompile versus new Visual Studio Project
The easiest way to get the web part working in 2010, would be to recompile the solution in Visual Studio 2010 with updated references to the 2010 assemblies. Because I wanted to take advantage of the new SharePoint development tools in Visual Studio 2010, I decided to create a new Visual Studio project instead. It is a bit more work, but you end up with a Visual Studio solution that is using the latest and greatest in SharePoint development. So here we go:
- Create a new project in Visual Studio using the “Empty SharePoint Project” template
- Use the .NET Framework 3.5:
- In the ‘SharePoint Customization Wizard’, I selected Deploy as a farm solution. In the project that I am migrating from SharePoint 2007, I am using some features that will not work in a sandboxed solution (like custom aspx pages in the LAYOUTS folder and custom ascx controls). In one of the next steps of this project I will see if I can get rid of this and deploy Content By Type as a sandbox solution.
- Set the references to the SharePoint 14 assemblies.
Add ASPX and ASCX files
The editor uses an ASPX page and a number of ASCX controls. In Visual Studio 2008 these files were added to the Layouts folder of the ‘12’ folder in the project. Visual Studio now has the concept of SharePoint mapped folders. One of them is the Layouts folder. I wanted to stick to Visual Studio as much as possible, so I decided to leave the custom ‘12’, ‘12HIVE’ or ‘SharePointRoot’ folders as I used to call them.
- Right click your project file
- Select Add and select the “ShrePoint Layouts Mapped Folder”
- This mapped folder maps to a physical folder on your hard drive, in the normal project structure. I copied all files to this folder and added them to the project:
- In the ASPX and ASCX files I checked all the references to the 2007 versions of the SharePoint assemblies and updated them to the 2010 version:
I just updated the version number from 12 to 14. The public key token remains the same.
Add the web part code
Visual Studio 2010 organizes web parts a bit different than you are used to. I decided not just to copy my webpart files to the new VS project, but to do it the Visual Studio 2010 way.
- To organize things a bit, I created a normal project folder for the ContentByType web part.
- On the new folder, right click, select Add and add a web part. I choose not to create a Visual Web Part, because they did not exists in VS2008, and therefore my web part is an ‘ordinary’ web part:
- Visual Studio just added a number of items to your project, all packaged as 1 item:
- The web part CS file.
- The .webpart file containing the metadata.
- The elements.xml file for the feature.
- Copy the web part code. I manually copied the code from my web part CS file into the new CS file just created by Visual Studio.
- In the ContentByTypeWebPart.webpart file, I copied all the metadata about the web part from the properties in the old version of the web part file.
- In the Elements.xml file, I changed the group in which the web part will be displayed in the web part gallery.
- Copy the other CS files to the project. I created a number of folders and added all other necessary CS files.
- Now all code is in my project, I renamed the namespaces I used in the 2007 project to my new namespace.
Replaceable parameters
Another cool new feature of Visual Studio 2010 is Replaceable parameters. These are tokens that you can add to any file that gets packaged by Visual Studio. These tokens are replaced by Visual Studio automatically. An example of such a parameter is $SharePoint.Project.AssemblyFullName$. This gets replaced by the full 4 part assembly name. These parameters are used by Visual Studio itself when you for example add a new web part to your project and look in the .webpart file:
<webPart xmlns="http://schemas.microsoft.com/WebPart/v3">
<metaData>
<type name="TST.SharePoint2010.WebParts.ContentByType.ContentByTypeWebPart.ContentByTypeWebPart, $SharePoint.Project.AssemblyFullName$" />
<importErrorMessage>$Resources:core,ImportErrorMessage;</importErrorMessage>
</metaData>
So you now never have to lookup your public key token again! I changed all the assembly references in the ASPX and ASCX files used by the Content By Type web part to the parameter $SharePoint.Project.AssemblyFullName$:
<%@ Control Language="C#" Inherits="TST.SharePoint2010.WebParts.ContentByType.ContentTypeConfiguration, $SharePoint.Project.AssemblyFullName$" %>
<%@ Assembly Name="Microsoft.SharePoint, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" %>
<%@ Register TagPrefix="TST" Assembly="$SharePoint.Project.AssemblyFullName$" Namespace="TST.SharePoint2010.Shared.WebControls" %>
The magical moment: Hit F5
When everything compiled, the magical moment came. I pressed F5. And of course it worked! Nice work, with just a bit of work I had the first version running on 2010. Next step will be to get rid of the popup dialog for the editor. I want it to use the ribbon and the out of the box SharePoint 2010 dialog look and feel. And I might go for a Silverlight editor also.
Summary
In this post I have described my first steps on the road of code migration to SharePoint 2010. Instead of doing a recompile I decided to upgrade my Visual Studio solution to the 2010 way to do things. Hope this gives you a starting point if you are planning to do the same for your solutions. Although it is a bit of manual work, I would recommend to go for it, and also upgrade your solution to take advantage of the new tooling.