Lors de la mise en place d’un portail sharepoint, il arrivera toujours un moment ou l’utilisateur vous demandera des affichages, des comportements qui ne sont pas natifs.
Pour faire de la customisation de comportements, de composants, un expert Sharepoint (architecte) m’a expliqué qu’il existe 2 types de projets de développement:

• type solution
• type sandbox

Faisons un peu d’histoire.

Le projet de type « solution » :

Dans Sharepoint 2007 il n’existait qu’un seul type de projet : solution. L’administrateur sharepoint receptionnait le WSP (résultat du développement) et l’incluait dans la ferme sharepoint.  Aujourd’hui le type projet solution fonctionne toujours comme cela : il faut les droits d’administrateur pour déployer un WSP.

• Le risque de ce type de solution est le suivant : si le WSP contient une boucle infinie, la ferme sharepoint pourrait potentiellement  crashée et il faudrait désactiver le bon composant. Cette tâche peut être compliquée quand on a beaucoup de WSP specifiques. 
• De plus beaucoup d’hébergements de portails Sharepoint se font à travers des VM. Or plusieurs portails peuvent être placés sur une même machine. Le risque est donc encore plus grand de pertuber les autres portails…
• Pour plus de sécurité il faut donc que l’administrateur puisse tester le WSP sur une autre ferme sharepoint pour être sûr du fonctionnement de ce dernier…

Le déploiement de WSP n’est donc pas anodin.

Le projet de type « sandbox » :

Depuis sharepoint 2010 il existe ce type de projet qui permet :

• de tester et débugger  plus facilement ( upload du composant dans une page et  tests possibles immédiat (explications dans un prochain post))
• de déployer directement dans une « site collection » sans avoir les droits d’administrateur sur la ferme : il est juste nécessaire d’être administrateur de la « site collection ».
• de ne mettre en danger entre guillemet qu’une partie restreinte de la ferme sharepoint 
• de plus le code est supervisé : si la ressource prise par ce WSP est trop importante, sharepoint le désactive automatiquement
• les inconvénients majeurs sont que le développeur est quand même limité. Exemple pas possible de faire d’upload de file ou d’utiliser l’envoie de mail. Il faudra pour réaliser ce genre de composant repasser dans un projet de type solution

Le type de projet sanbox est plus facilement manipulable pour les débutants de la personnalisation de sharepoint.

Lors de l’interview d’un autre expert sharepoint (développeur de features), ce dernier a confié qu’il ne créait jamais de projet de type sandbox pour ne jamais être limité.

Si vous aussi vous avez des retours d’expériences n’hésitez pas à commenter…