Bienvenue à Blogs CodeS-SourceS Identification | Inscription | Aide

The Mit's Blog

En plus d'intégrer et skier, il sait même écrire !
(Blog de Renaud Comte)

Actualités

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 :

image

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 !

image

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

imageimage

Etape 3 : génération du projet

image

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

image

Mais je n’irai pas plus loin sur le sujet Sourire

Import des slns de WSPBuilder

image

“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 : 

image

Sinon, quelques captures d’écran de test de certaines de mes applis

Etape 1 : Création du projet

image

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

image

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 typeimage
    • 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 …

image

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

Mots clés Technorati : ,,,,
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 :
Posted: jeudi 5 mai 2011 12:55 par themit

Commentaires

nicoboo a dit :

Hey ! Merci pour le clin d'oeil :)

Qu'en est-il du respect des bonnes pratiques dans les solutions Visual Studio 2010 :

- Localisation :

La localisation n'est supporté à aucun niveau dans la génération des éléments (ItemTemplates ou ProjectTemplates non pensés pour la localisation, de même pour ceux fourni pas les CKS Dev extensions... quand on est anglophone... on ne pense pas qu'il peut y avoir des bonnes pratiques à ce niveau là... c'est comme pour la sérialisation des doubles/float ou encore des Dates à stocker en UTC... mais bon... c'est un autre sujet).

Bref, pour pouvoir fournir une feature et des composants parfaitement localisés à tout niveau et cela peut aller très loin (exemple : localisation des valeurs d'un field choice que l'on souhaite provisionner; mais même la localisation du simple titre et description de la Feature n'est pas supporté).

- Generation de package :

Pouvoir le faire sans VS2010 installé et génération de scripts de déploiement / upgrade + dossier prêt à l'emploi pour livraison. Ca deploie "magiquement" dans le 14 ou via packaging WSP (add and deploy) mais le développeur ne voit pas la merde qu'il génère dans son package et est incapable d'en mesurer l'impact.

Exemple : pourquoi un projet de déploiement de master déploie-t-il par défaut une DLL dans le GAC ? Il faut modifier la propriété du projet manuellement, ce qui n'est pas dans la philosophie du reste de l'outillage fourni autour de SP2010 dans VS2010.

Pour ma part, et par expérience, après avoir outillé mon VS2008 pour mes développements SP2007, je trouve que les outils de développement pourt la version 2010 sont une vraie fausse innovation qui ressemble en réalité à un retour en arrière.

Dans l'article qui traite de la migration, et non des bonnes pratiques, il faut aussi considèrer les lacunes des nouvelles versions des outils de développements.

Pour rendre le développement plus simples, on ne doit pas passer outre les bonnes pratiques, c'est malheureusement ce que tend à faire cette nouvelle version de VS2010 pour les développements SP2010.

Ca ne me fait pas gagner en temps si je veux fournir la même qualité de livrable, je dirai même que ça m'en fait perdre, mais je comprends tout à fait que ton article n'était pas écrit dans ce but, mais je trouve important de souligner ce manque incompréhensible et ces choix techniques en termes de fonctionnalités et respects des bonnes pratiques qui m'ont, autrefois, fait m'arrache les cheveux :)

# mai 5, 2011 11:10

nicoboo a dit :

J'ajouterai que la nouvelle version de WSPBuilder reprends les mêmes erreurs de non-respect des bonnes pratiques au niveau de la localisation que sa version pour SP2007.

Aller modifier les fichiers XML à la main à l'heure du "tout par interface", ce n'est pas un gage de réussite en termes d'adoption voir un gros risque pour les développements lorsque cette tâche sera réalisée par les développeurs non expérimentés ou qui ont commencé sur 2010 ou en utilisant bêtement les outils (WSPBuilder, STSDev, Extension VS) de 2007.

# mai 5, 2011 11:17
Les commentaires anonymes sont désactivés

Les 10 derniers blogs postés

- Emportez votre sélection de la MSDN dans la poche ? par Blog de Jérémy Jeanson le il y a 19 heures et 19 minutes

- [ #Office365 ] Pb de connexion du flux Yammer ajouté à un site SharePoint par Le blog de Patrick [MVP SharePoint] le 04-17-2014, 17:03

- NFluent & Data Annotations : coder ses propres assertions par Fathi Bellahcene le 04-17-2014, 16:54

- Installer un site ASP.net 32bits sur un serveur exécutant SharePoint 2013 par Blog de Jérémy Jeanson le 04-17-2014, 06:34

- [ SharePoint Summit 2014 ] Tests de montée en charge SharePoint par Le blog de Patrick [MVP SharePoint] le 04-16-2014, 20:44

- [ SharePoint Summit 2014 ] Bâtir un site web public avec Office 365 par Le blog de Patrick [MVP SharePoint] le 04-16-2014, 18:30

- Kinect + Speech Recognition + Eedomus = Dommy par Aurélien GALTIER le 04-16-2014, 17:17

- [ SharePoint Summit 2014 ] Une méthodologie simple pour concevoir vos applications OOTB SharePoint de A à Z par Le blog de Patrick [MVP SharePoint] le 04-16-2014, 16:51

- //Lean/ - Apprendre à faire des Apps Windows universelles par Blog de Jérémy Jeanson le 04-16-2014, 12:57

- Une culture de la donnée pour tous… par Le blog de Patrick [MVP SharePoint] le 04-16-2014, 11:00