Migrating a solution from 2007 to 2010

Question

Let's say we have a well-established solution in Visual Studio 2008, using WSPBuilder to bundle it up into a package. It has a handful of features and a whole whack of assets to deploy (.webpart, .xsl, .js, images, site columns, content types, etc.) to both site collection libraries and the 12 hive.

What would you suggest the approach should be for going to 2010?

I have an odd feeling that SPI folders (as lovely as they are for managing Module Elements) are going to get pretty busy and hard to manage in a VS2010 solution with several features in the one project. So, would you still use WSPBuilder, and have your 14/TEMPLATE/FEATURES/etc folder hierarchy in the project?

Also, I horrendously dislike the "Solution" and "Feature" design surfaces, especially so when you have a VS2010 Solution with several projects, each with a handful of features.

Anyone else have experience with medium-sized-and-up VS2010 solutions yet?

Also: the assumption is that the 2010 solution will be deployed to the Farm.

Answer 1

WSPBuilder in CKS: Development Tools Edition Extension for VS2010. http://cksdev.codeplex.com/

PS. Must have this extension for SP development.

Answer 2

We did a recent migration from 2007 to 2010, medium sized project (Silverlight webparts, 30+ other webparts, wfc, images, js, list defintions, Feature receivers and lot more). We converted all the webparts to Visual WebParts (we determined Farm Solution is ok), including namespace conventions. (Had to recreate webparts in publishing pages though). We also used the SP Map Folder capability of VS2010 to add Layouts, Images folders. Our old code had hard-coded 12 HIVE directories, we changed them to use 14 HIVE via appSettings. Also we decided to bundle all in one feature.

I use three extensions - SP Power Tools, Productivity Power Tools and PowerCommands for VS2010. I do not use WSPBuilder anymore, but use the built-in deploy feature of VS 2010. Pretty useful.

Answer 3

My team has converted a large SP2007 WSP builder project to SharePoint 2010. A few important things to remember especially if you are upgrading the sharepoint content database as well:

When recreating features remember to use the same feature ids.

Do not change assembly names, namespaces for things like webparts and eventreceivers and other things that are referenced in the database.

Do not change the deployment location for sharepoint artifatcs. Unless you want to write a feature upgrade elements defining new location of required files, can be painful if large project.

Use the correct sharepoint project item when recreating. If not, specific functionality might be missing from Visual Studio for that project item.

In most cases the following workflow works quite well. Create new webpart item in VS2010 -> replace ids,element files and code from WSP 2007 project -> Do some tweaks.

With CKS-Dev and VS2010 the development experience is great.

Answer 4

I have migrated a solution with more than one feature and some assets deployed to the layouts folder from 2007 to 2010. I was happy with the out of the box experience in Visual Studio 2010 after I got used to it. The migration was a bit more manual than I expected at first, but overall, not overly complex. I recommend starting the migration with the Out of the Box tools to help build familiarity with them. That could reduce your future dependence on third-party tools that may not upgrade well or be maintained as well as full MS supported tools.

Answer 5

See our 4 part series about Porting a SharePoint 2007 WSPBuilder solution to SharePoint 2010.