SharePoint 2010 est venu avec son lot de nouveautés. Parmi elles, l’amélioration de l’expérience “F5” ainsi que le support du développement sur Windows 7. Le principal avantage de ce type d’installation est de ne pas avoir à gérer de machines virtuelles et donc que les performances soient au maximum : on tourne directement sur la machine. Or, pour pouvoir profiter de la connexion VS2010/SharePoint (pour les déploiements de WSP par F5 mais aussi pour l’explorateur de serveur), il faut que SharePoint soit installé localement sur la machine exécutant Visual Studio.

Ayant eu à travailler sur un projet en SP2010, je me suis lancé et j’ai fais tous mes développements directement sur mon Windows 7.

Pour commencer, je recommande de se référer à l’article MSDN "Setting Up the Development Environment for SharePoint 2010 on Windows Vista, Windows 7, and Windows Server 2008" :

http://msdn.microsoft.com/en-us/library/ee554869.aspx

La première surprise vient quand on essaye d’installer SharePoint. De base, le programme d’installation échoue avec le message d’erreur suivant :

MSDN explique que pour passer outre ce message il faut extraire les fichiers du programme d’installation SharePoint (soit de l’ISO soit de l’EXE en utilisant le commutateur /extract: , selon le livrable qu’on aura récupéré). On pourra regréter que ce ne soit pas natif .

Dans le répertoire d'extraction, on modifie ensuite le fichier "Files\Setup\config.xml" pour y ajouter :

En relançant le programme d'installation, on constate alors qu'il se déroule normalement. Il faut choisir entre mode Standalone et Farm.

Ca va porter à débat entre ceux qui préfèrent un Farm sur 2008 R2 ou un Standalone sur Windows 7 mais la différence entre les 2 ne se limite qu’à ce qui sera installé par défaut : Standalone va installer un SQL Express et provisionner tous les services SharePoint. Ayant déjà mon SQL Server 2008 R2 qui va bien et ne souhaitant avoir que certains services, j’opte donc pour le mode Farm.

Arrivé à l’assistant de configuration, une deuxième surprise arrive :

Ce problème est lié au choix du mode d’installation, le mode ferme imposant l’utilisation d’Active Directory. Une rapide recherche sur le net indique comment passer outre ce message grâce à des commandes PowerShell.

La commande New-SPConfigurationDatabase permet de créer la base de configuration avec le login de notre choix sans se soucier si c’est un compte local ou de domaine. Ensuite, le plus simple est de relancer l’Assistant de configuration, de préciser qu’on ne souhaite pas se déconnecter de la ferme (puisqu'on l'a créé en powershell) et qu’on veut provisionner l’Administration Centrale.

Si vous souhaitez continuer à faire du PowerShell, l’alternative à l’Assistant est d’utiliser la commande New-SPCentralAdministration.

Important à noter, les comptes utilisés par SharePoint sont maintenant référencés dans l’Administration Centrale (Managed Accounts) :

Quand on a provisionné l’Administration Centrale, le compte que nous avons spécifié a été enregistré. Toutefois, si on souhaite ajouter d'autres comptes locaux (pour bénéficier d'une identité différente pour nos applications de service par exemple), là encore SharePoint refusera à moins de passer par PowerShell via la commande New-SPManagedAccount. En effet, si on essaye de rajouter le compte par l’Administration Centrale, on aura en rouge le même message indiquant qu’il s’agit d’un compte local.

Comme tout ça peut devenir vite fastidieux, j’ai utilisé pour installer mon SharePoint le script http://autospinstaller.codeplex.com qui permet d’automatiser le tout par un simple fichier de config XML :

(Vous noterez que l’utilisation des comptes locaux ne donne lieu qu’à un WARNING en PowerShell et pas une erreur comme dans l’interface graphique ).

UAC

Un petit point sécurité, si vous avez laissé l’UAC activé sur votre Windows 7 (vous devriez !), si on essaye de naviguer sur l’Admin Centrale depuis un IE qui n’est pas élevé, certains boutons de l’interface seront grisés. Donc pensez à passer par le lien du menu Démarrer :

De plus, Visual Studio se plaindra également de ne pas pouvoir déployer les WSP s’il n’est pas exécuté en tant qu’Administrateur.

Conclusion

J’ai pu expérimenter cette configuration et j’ai été assez impressionné par la fluidité de MSS quand il n’est pas virtualisé. Je peux ainsi profiter des 6GB de mon portable avec de bonnes performances et aussi de mon Windows 7 avec mes différentes applications. Le principal inconvéniant est que si on me demande une copie de l’environnement de développement, c’est impossible le dupliquer commme on ferait pour une VM (ce qui ne me dérange pas vu que je préfère avoir mes environnements de dev avec mes outils configurés comme je les aime).

Il y a tout de même un point à adresser : le manque d’un AD pour gérer les identités dans SharePoint. Dans un prochain article, je vous montrerai comment j’ai comblé ce manque dans mon projet en utilisant les Claims ainsi qu’un AD LDS.