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

I need to change the name and installation directory of some features that are already deployed in a client's environment.

I can change the feature name from the feature designer, and change the installation directory from the properties dialog. I'm testing this in my environment, when I upgrade the solution (using CKSDEV) I get the following error:

Error occurred in deployment step 'Upgrade Solution (CKSDev)': The solution cannot be deployed. The feature 'b08afe0a-0b46-46b5-99a9-b9fa5ca16671' uses the directory "MyProject_MyFeature" in the solution. However, it is currently installed in the farm to the directory "MyFeature". Uninstall the existing feature before you install a new version of the solution.

Sure I can uninstall and reinstall the feature in my development environment, but I can't do that in the client's production environment. Is there any way around this?

There's a similar question here, but the resolution was to change the feature installation directory to match the old one, hence avoiding this issue.

EDIT: There's an impact to uninstalling/reinstalling features, e.g. if the feature has a list definition and instance, I'll lose data in the list (this is apparently not true). That's why I'm trying to figure this out with an upgrade.

share|improve this question
add comment

1 Answer

up vote 5 down vote accepted

SharePoint doesn't delete either list or its data on feature deactivation or deinstallation, at least if it was created through CAML (Elements.xml, schema.xml).

Probably you're using Visual Studio deployment in your testing environment, and it is Visual Studio who deletes the list, treating its existence as a deployment conflict. But if you re-deploy through PowerShell or stsadm, or re-activate feature through GUI, the list will not be deleted - I promise you.

Thus, unless you have written the deletion code yourself, there is nothing to worry about.

share|improve this answer
    
Thanks omlin, you're right, the Visual Studio deployment is probably the culprit. I'll try this out in my development environment. Thanks –  George Durzi Jan 6 '12 at 20:22
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.