1

I'm moving from a WSPBuilder based SharePoint 2010 solution to a Visual Studio 2010 based solution. After porting the WSPBuilder based solution to a plain Visual Studio based solution I tried to deploy the new solution. Solution names and ids as well as feature names and ids are the same but Visual Studio complained because I was trying to deploy the new features to other directories than the original features.

WSPBuilder deploys features to directories with the same name as the directory/folder in Visual Studio. Visual Studio on the other hand deploys features to directories named after the Visual Studio project and the feature name.

I'm a little bit afraid of how to handle this in a client's production environment. In order to move to a VS solution I would have to retract the solution in production and then deploy the new solution. So, what happens to the 100s of sites in which the features are active? Can the feature upgrade framework handle this?

1 Answer 1

1

OK, digging around made me realize that I needed to understand how Visual Studio generates the folder name and if it could be tweaked. And, of course, it can.

Every feature has a property called Deployment Path. This is set to the replaceable parameter:

$SharePoint.Project.FileNameWithoutExtension$_$SharePoint.Feature.FileNameWithoutExtension$

by default. Changing this to:

$SharePoint.Feature.FileNameWithoutExtension$

for all features will give me the same behavior as WSPBuilder.

So, you can safely port your WSPBuilder solutions to the new Visual Studio way of doing things, if you want to of course.

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.