Avant tout cet article se veut être un retour d’expérience sur un cas assez particulier du développement SharePoint. Les produits et composants telerik sont de très bons produits qui permettent d’accélérer vos développements (SharePoint ou non) en vous fournissant des contrôles utilisateurs poussés et paramétrables à souhait.
Certains d’entre vous le savent déjà, je travaille dans une équipe qui développe des produits pour SharePoint (www.oceanik.com et les autres n’ont pas encore de site dédié, on a encore du travail côté marketing).
Développer du produit est assez différent du développement de solutions ponctuelles (pour répondre au besoin d’un client particulier dans un contexte particulier). En effet votre produit va être déployé dans une myriade d’environnements complexes et différents et être utilisé pour un même besoin initial mais de manières variées.
Dans ce contexte nous avons utilisé des composants télérik dans nos produits SharePoint. Après plusieurs mois sans problèmes certains de nos clients nous sont revenus en nous indiquant que depuis l’installation de nos produits certaines de nos fonctionnalités ne fonctionnaient pas correctement ou bien que d’autres développements ne fonctionnaient plus du tout.
Le problème ? Ils avaient déjà une version de télerik déployées, soit via les composants télérik pour SharePoint (qui embarquent les composants télérik pour asp.net que nous utilisions) soit à cause d’autres produits/développements customs. Les versions rentraient en conflit.
La solution ? Faire de la redirection d’assemblies me direz-vous. Oui mais voilà, quand on emploie ce genre de technique il faut dire que telle version demandée spécifique correspond à telle version sur le système. Si c’est quelque chose sur lequel on peut accompagner le client, il est difficile d’industrialiser le processus, car impossible de savoir à l’avance quelle version aura le client. Autre détail, les thèmes disponibles ont beaucoup changé au fur et à mesure des versions, ce qui faisait aussi planter nos fonctionnalités.
La vraie solution ? Nous avons dû nous débarrasser de télérik. Dans notre cas il s’agissait simplement de grilles, et nous les avons remplacées par des contrôles javascripts (kendo ui, du télérik en fin de compte).
De manière plus générale, le développement de solutions « full-trust » ne dispose malheureusement pas d’isolation de contexte d’exécution, c’est d’ailleurs ce qui a mené au nouveau modèle d’apps pour SharePoint. Mon conseil pour tous vos développements SharePoint full trusts : Réduisez au minimum possible (contraintes de coûts) vos dépendances à des composants tiers.
De la même manière localisez toujours l’utilisation de librairies javascript (ex jquery noconflict), vous ne savez jamais si un de vos clients n’aura pas une vieille version de la même librairie qui posera problème.
Evidemment tous ces problèmes ne se posent pas avec des apps, donc derniers conseils : ne faites des solutions full trust que si vous en avez absolument besoin.