Take the 2-minute tour ×
SharePoint Stack Exchange is a question and answer site for SharePoint enthusiasts. It's 100% free, no registration required.

Does anybody have experience moving SharePoint 2007 features from VS2008 to VS2010 using the new feature designer? I currently have a C# class library project that has a "12" folder with a bunch of sub folders (FEATURES, LAYOUTS, etc...) and we are using WSPBuilder to generate the solution packages. I would like to move these projects into VS2010 and take advantage of the packaging and deployment functionality built into the IDE. Is there a straightforward way of doing this?

share|improve this question
add comment

2 Answers 2

up vote 5 down vote accepted

There isn't a 100% straightforward way of migrating WSPBuilder projects to 2010 unfortunately. At the time of writing, it's a little-known fact that WSPs from 2007 cannot be imported to 2010, thus ruling out that approach - see http://msdn.microsoft.com/en-us/library/ee231584(VS.100).aspx.

If I needed to be 100% sure about my final output, I'd probably use an approach something like:

  1. Create the 2010 version of the VS project(s).
  2. Add the file for each of the 'complex' files in the SharePoint root 'manually' through the VS2010 menu options (this is to ensure any new attributes are added/any slight schema changes are accounted for).
  3. Add the first element (e.g. content type) through VS2010.
  4. Paste in the declaration of other (e.g.) content types, comparing the XML to that of the 'native' 2010 element. Manually fix-up any missing attributes etc.
  5. Add the rest of the files e.g. .cs/.aspx/.ascx etc etc.
  6. Deploy and work through initial errors. Some of these could be down to files not having the correct 'DeploymentType' attribute, or from files going into the wrong Feature.
  7. Test test test.

An example of the kind of difference this process attempts to protect against is the fact that the ContentType element now has a new 'Inherits' attribute. Additionally, 'FieldRef' elements now should use 'DisplayName' in addition to 'Name' and 'ID' (I've not confirmed this, but the info is from someone in the Product Group).

Bear in mind that it's only 'complex' elements which provision into the content database which are likely to of concern e.g. fields, content types, list instances etc. Something as simple as an application page can be shipped into the VS2010 project more simply. Also consider that you now have greater freedom of structuring your VS2010 project into meaningful folders - you no longer need to use the 'runtime location' approach (12 folder) of WSPBuilder.

An alternative could be to do an in-place upgrade on a VM somewhere, then save the resulting site as a WSP, then import to VS2010. Although it should work on paper, I'd need to see more concrete evidence before saying it would really work though.

share|improve this answer
    
Thanks for the answer, Chris. That is essentially what I was doing when I experimented with the VS2010 RC. I was just hoping there was an easier way. It's important that our feature IDs stay the same when the features get "ported". I ran into some issues editing the feature manifest directly in VS, where in some cases the VS-generated feature IDs were still hanging around in some of the "hidden" files. –  jason.venema Apr 6 '10 at 19:15
add comment

One technique I have used is to convert my SharePoint 2007 projects to VSeWSS 1.3 March CTP. The VSeWSS import tool is released]1 and converts your project to a Visual Studio 2010 project targeted at SharePoint 2010.

Unlike previous versions of the tool, as of March CTP, VSeWSS addresses most developer needs. Paul Andrew and Kirk Evans provide excellent guidance on how to get up to speed with the new features that were missing from previous versions.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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