Modification du nom de répertoire de fonctionnalités dans SharePoint 14 Hive - Impact sur les fonctionnalités déjà déployées?

Question

Je me déplace d'une WSPBuilder solution basée sur SharePoint 2010 à une solution basée sur Visual Studio 2010. Après le portage de la solution de WSPBuilder à une solution Visual Studio simple j'ai essayé de déployer la nouvelle solution. Les noms de solutions et ids ainsi que les noms des fonctions et ids sont les mêmes, mais Visual Studio se plaint parce que je tentais de déployer les nouvelles fonctionnalités à d'autres répertoires que les caractéristiques d'origine.

WSPBuilder déploie des caractéristiques des répertoires avec le même nom que le répertoire / dossier dans Visual Studio. Visual Studio sur les autres Déploie main propose aux répertoires du nom du projet Visual Studio et le nom de la fonction.

Je suis un peu peur de la façon de gérer cela dans l'environnement de production d'un client. Pour passer à une solution VS je dois rétracter la solution dans la production puis déployer la nouvelle solution. Donc, ce qui arrive aux 100s de sites où les caractéristiques sont actifs? La poignée peut-cadre de mise à niveau de fonctionnalité cela?

Answer 1

OK, creuser autour de moi fait comprendre que je devais comprendre comment Visual Studio génère le nom du dossier et si elle pourrait être modifié. Et, bien sûr, il peut.

Chaque fonction a une propriété appelée chemin de déploiement. Ceci est réglé sur le paramètre remplaçable:

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

par défaut. La modification de ce à:

$SharePoint.Feature.FileNameWithoutExtension$

pour toutes les fonctions me donnera le même comportement que WSPBuilder.

Alors, vous pouvez en toute sécurité le port de vos solutions de WSPBuilder à la nouvelle façon de Visual Studio de faire les choses, si vous voulez bien sûr.