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.

  • As an extra for the whole migration I would go for an application I found so easy to use it is astounding, not only is it handling from 2003 up to 2013 it is handling 365 also, 2007 to 2010 is a cakewalk. The application is metavis by metavistech, and if the client/company has the budget this is the best way to perform any migration. And no I don't work for them but I gladly bought a 500gb transfer off them.
    – Hugh Wood
    Nov 7, 2012 at 17:27

5 Answers 5


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

PS. Must have this extension for SP development.

  • Good plan, I also have the SharePoint Power Tools for VS2010 extension, has some very useful stuff in there.
    – James Love
    Apr 8, 2011 at 17:33
  • I use SP Power Tools too. Also would recommend Linq to SP DSL extentions and caml.intellisence.
    – gandjustas
    Apr 8, 2011 at 17:39
  • very nice answer. Aug 22, 2011 at 12:48
  • updated download link: visualstudiogallery.msdn.microsoft.com/…
    – mhijazi
    May 28, 2014 at 16:25

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.


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.


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.


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

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.