Migration de code SharePoint 2007/2010 : différentes pistes et outils
Basiquement
Maintenant que SP2010 existe aussi bien en version serveur qu’online, il se pose toujours la douloureuse question de la migration de son existant
Je ne vais pas parler dans ce post de la migration du contenu mais plutôt de la partie “source code” tant désirée par nos amis les développeurs
Historique
La plupart des projets sous SharePoint 2007 ont réussi à être déployés en solution WSP certainement grâce à un projet phare : le WSPBuilder (et ses non moins fameuses extensions VS)
http://wspbuilder.codeplex.com/
Oui, certes, qqun écrivaient fièrement leur MakeCab et Manifest.xml (salut nico) où utiliser les VSeWSS (euh non, salut personne de mes connaissances en tout cas) mais majoritairement, WSP Builder revenait sur le devant de la scène
imaginez donc :
Soit de nombreux, nombreux projets VS 2008 avec un répertoire 12 en racine présent dans nos gestionnaires de sources à migrer.
Migrate the source or not ?
Je maintiens, la question se pose vraiment : faut il migrer vos sources ?
Pas vraiment, le code et le packaging de SP2007 fonctionnent toujours sous SP2010 avec ou sans le Visual mode upgrade
Certes, si la problématique touche à des composantes de l’UI comme la master, on ne se pose pas vraiment la question mais majoritairement, vos “custom devs” continueront à fonctionner assez bien sous SP2007
…
Seulement, voila … En cas de maintenance, correction de bug, évolution ou simple petite modification, vous allez devoir réutiliser une ancienne VPC avec
- SP2007
- VS2008
- WSPBuilder ?
et faire cohabiter des sources sous VS2010 avec en parallèle.
Bref, le début des soucis pour ne pas dire plus
Moralité : Si vos apps ne changent jamais, migrer leurs sources en fonction ou définitivement, faites le pas et profitez de la revalidation suite à la migration de votre portail pour convertir vos solutions 2007 en VS 2010
Et en pratique
Le travail de conversion peut être éprouvant voir fastidieux :
- reprendre le code
- recréer les artifacts et autre SP Items
- reprendre la structure logique du 12 en mapped folder
- …
Mais il y a moyen de gagner un peu de temps, en cherchant un peu dans la communauté MS
Import de WSP sous VS2010
Simple et très efficace : vous pouvez créer un nouveau projet VS2010 avec le template d’import de solution SharePoint !
Certes, ce template est prévu pour travailler de concert avec SPD et les galeries de SharePoint mais vu que le schéma est compatible, pourquoi ne pas en profiter avec nos chez vieux WSP sauce 2007 ?
Etape 1 : Création du projet + Url du site
Etape 2 : sélection du WSP et des éléments d’import
Etape 3 : génération du projet
Un fois importé, votre WSP se transforme en une vraie solution VS avec l’ensemble des artifacts déjà configurés. Seul petit souci prévisible, le code réside toujours dans une dll qu’il faudra reprendre. Cependant pour des projets tournés autour du déclaratif CAML et les Features, c’est efficace.
Limite, ça peut être une solution de reprise rapide en cas de perte des sources : vous extrayez les WSP de la central admin pour profiter ensuite de VS 2010 pour reprendre la partie configuration/déclaration de vos solutions !
http://blogs.developpeur.org/spbrouillet/archive/2010/10/05/powershell-recuperer-les-wsp-d-une-ferme-sharepoint.aspx
http://manish-sharepoint.blogspot.com/2010/05/retriving-sharepoint-wsp-files-from.html
Quelques remarques cependant après le test de 4 solutions 2007 issues de projets d’un de mes clients :
- Les Dlls sont ajoutés en racine de projet dans un dossier “Other Imported Files”
- Les artifacts de SP, soit les items de feature, module, Fields, CT et autre WebPart sont reconnus parfaitement : GOOD
- Les Mapped Folders se résument souvent à des sous dossiers de Template : dommage, on sent l’inspiration du chemin relatif au 12/template mais en rien gênant au final
- Chaque element.xml est placé dans un module avec un compteur
- La référence de SP.dll est faite sur la version 14 : tant mieux
- Reprise des resx dans les noms de Feature, normal mais surprenant à la première lecture
- Mais le nom des feature items reste Feature 1, 2, 3 …
En dehors du code et des DLL, parfait pour réorganiser et préparer une version 2010 plus personnelle
Import des sln de VSEWSS sous VS2010
J’ai beau plaisanter dessus, mais il y a quand même quelques centaines de projets fait avec ce sympathique VSEWSS. Microsoft joue son rôle d’éditeur et, en plus de nous avoir gratifiés d’une suite d’outils SP pour VS2010, bien ils ont rajouté un outil d’import
VSeWSS Import Tool for Visual Studio 2010
Mais je n’irai pas plus loin sur le sujet 
Import des slns de WSPBuilder
“Last but not least”
http://solutionarchitects.org/articles/2011/04/06/migrating-code-from-moss-2007-to-sharepoint-2010.htm
La dernière version du CKS Developement tool contient un nouveau petit outil : WSPBuilder project importer project template
Ce template de projet vous permet de créer une solution à partir du sln de vos sources VS2008 + WSPBuilder.
Le CKS reconstruit la solution VS2010 en se basant sur le contenu de la solution WSPBuilder de VS2008
>>> Attention, le projet est encore en beta mais déjà bien efficace
Vous êtes curieux ? Voici le Webcast :
Sinon, quelques captures d’écran de test de certaines de mes applis
Etape 1 : Création du projet
le CKS est toujours aussi bien intégré dans VS 2010, c’est vraiment impressionnant pour un projet Codeplex de voir une telle finition
Etape 2 : Génération de la solution
Déjà une belle réussite pour une première beta non ?
Quelques remarques :
- Meilleure reprise technique des noms des Features + utilisation des RESX : nickel
- Les Mapped Folders sont repris identiquement à ceux de VS (désolé pour les fans d’un SP Root)
- Tout est classé par répertoire, ça peut demander un peu de renommage
- en principe, si vous avez du contenu hors Mapped Folder, tout est classé dans un sous répertoire '”items” ensuite par type
- Chaque element.xml est placé dans un module avec un GUID
- Il récupère forcément tous les fichiers de votre solution avec le WSPBuilder, pensez à enlever vos batchs
Conclusion
De quoi être optimiste non ? Mais pour être tout à fait honnête, la conversion avec les outils, même le CKS (en beta) ne couvre pas encore 100% du périmètre.
Grave ? Pas vraiment car il faut reconnaitre qu’au moins 70/80% du boulot est viable !!!
Ce qui vous libère déjà beaucoup de contraintes de copie/revalidation des artifacts SharePoint pour vous permettre de ne vous concentrer que sur la solution 2010 et son réaménagement. Non ?
Il serait dommage que vous passiez à coté des ces outils lors de votre migration, le temps restera toujours une denrée précieuse et un ennemi juré en cas de calendrier délicat. Mais restez sur vos gardes, après tout ce sera toujours vous qui lancerez le script de build, donc validez bien les 10 derniers pourcents de votre travail !!!
PS : Pour ceux qui pensent que WSPBuilder est fini, sachez qu’il existe une nouvelle version beta pour SP2010
Elle reste toujours aussi intéressante mais il faut souligner le travail et le résultat qu’a produit Microsoft dans sa nouvelle suite SP avec VS2010 (que l’on a attendu si longtemps depuis SPS2001 …)
[Update]
Pour tenir compte des remarques passionnés et passionnantes de Nicoboo, je ne saurais trop rappeler que la qualité de votre code et du projet repose plus sur votre méthode de travail et la compréhension de votre outil que la qualité de VS 2010
N’oubliez pas que SP repose aussi bien sur des DLLs que du déclaratif !!! Evitez donc de créer des DLLS si vous déployez des Master Pages et des gabarits …
La gestion des ressources de langues et leur référence est bien géré au niveau framework SP mais complètement oublié des modèles de conception de VS2010 pour SP 2010. C’est certes dommage, souvent gênant pour ne pas dire bloquant dans des projets larges ou multilingues
Prenez donc le temps de lire ces articles lors de la conception de vos solutions SP :
Et dans le cas des Sandbox !!! (et oui les resx sont pas supportés en SB …)
Renaud Comte aka TheMit (Migratus, Importas et voilis Deployus omnibus)
Member of WygTeam
http://www.wygwam.com
Ce post vous a plu ? Ajoutez le dans vos favoris pour ne pas perdre de temps à le retrouver le jour où vous en aurez besoin :
