Bonjour à tous,
Chez Negotium technologies nous développons plusieurs produits pour SharePoint. (www.oceanik.com www.theattributesolution.com …)
Un problème assez complexe nous est récemment arrivé. Imaginez que ces deux produits aient une dépendance commune (newtonsoft.json pour ne pas la nommer). Maintenant imaginez que les deux produits soient installés sur une même ferme SharePoint et que pour une raison quelconque vous vouliez désinstaller uniquement un des produits.
Quand SharePoint va rétracter le wsp, il va naturellement rétracter toutes les dll’s qui étaient dedans. Y compris la dépendance commune dont l’autre produit a toujours besoin. Ceci va mettre en défaut l’autre produit.
Un administrateur avisé le remarquera rapidement et effectuera un install-spsolution <nomsolution> -GacDeployment –Local –Force sur chacun des serveurs impactés.
Cependant tous les clients n’ont pas la chance d’avoir des administrateurs correctement formés sur SharePoint. La question suivante se pose vite : comment s’assurer que ma solution sera assez résiliante pour se réparer toute seule dans ce genre de cas de figure ?
Après plusieurs réflexions, il apparait que SharePoint ne possède pas de système complet de résolution de dépendance. (en fait le problème vient de .NET en général et de Windows).
Certains développeurs SharePoint chevronnés me diront qu’il existe les ActivationDependency pour les solutions. Oui mais cela ne sert qu’au déploiement, rien n’empêche de rétracter une solution dont d’autres dépendent.
D’autres diront qu’on peut essayer de combler ce manque avec de la dépendance de fonctionnalités, qui elles vérifient les dépendances lors de la désactivation. Non les fonctionnalités sont là pour le provisionnement d’éléments, de plus rien n’empêche techniquement quelqu’un de rétracter une solution qui comporte des fonctionnalités toujours activées (même si c’est très mal de le faire).
Du coup la seule solution technique pour résoudre ce problème (et j’ai aussi pris le temps d’échanger avec l’équipe produits SharePoint sur le sujet) c’est de faire un timerjob sans aucune dépendance qui va venir vérifier si nos dépendances sont là et si elles sont absentes redéployer les solutions.
Vous trouverez un exemple ici.
Encore une fois, si vous pouvez faire des apps au lieu de solutions full trust, envisagez-le, vous n’aurez pas ce genre de problème ;-)
PS : je tiens à remercier les gars de mon équipe pour avoir passé du temps à réfléchir sur le sujet à savoir Benoit, Pascal, Yann, Sébastien, Jeff et Jordan.