Meilleur auteur de réponses
Visual Studio 2008 et WSS 3.0

Question
-
Est-ce que quelqu'un peut me dire si VS 2008 apporte des nouveautés au niveau du développement WSS 3.0?
Actuellement, pour développer des Web Parts avec WSS 3.0, il faut installer VS 2005 sur Windows Server 2003. De plus, il faut aussi installer les extensions de Sharepoint à VS 2005.
Est-ce encore le cas avec Visual Studio 2008?
Merci
Réponses
-
Bonjour,
Il semble que oui. Il existe un Livre Blanc sur Visual Studio 2008 indiquant un mécansime natif pour créer et bébogger des WorkFlows pour SharePoint... à voir jusqu'à quel point les extensions SharePoint sont inclues dans le produit.
Vous trouverez ce Livre blanc ici : http://www.microsoft.com/downloads/details.aspx?familyid=17319EB4-299C-43B8-A360-A1C2BD6A421B&displaylang=fr
Bonne lecture.
Toutes les réponses
-
Bonjour,
Il semble que oui. Il existe un Livre Blanc sur Visual Studio 2008 indiquant un mécansime natif pour créer et bébogger des WorkFlows pour SharePoint... à voir jusqu'à quel point les extensions SharePoint sont inclues dans le produit.
Vous trouverez ce Livre blanc ici : http://www.microsoft.com/downloads/details.aspx?familyid=17319EB4-299C-43B8-A360-A1C2BD6A421B&displaylang=fr
Bonne lecture. -
J'avais vu la même information, mais j'aurais espéré plus. Donc, je suis mieux de m'habituer à ce que mes développeurs utilisent une VM pour développer. C'est la licence de Windows Server 2003 par développeur et le déploiement des patches de sécurité pour ce OS qui me font le plus mal.
Merci
-
Le mode VM est celui que j'utilise. A noter néanmoins qu'il est possible de développer pour SharePoint sur un OS de type Windows XP : Visual Studio a bésoin des références aux librairies SharePoint (Microsoft.SharePoint.dll, Microsoft.Office.Server.dll, ...). Il est possible de copier les assemblies du GAC d'un serveur SharePoint sur le poste du développeur et de s'en servir pour développer.
Avec une telle configuration, pas de déploiement automatisé, et surtout pas de debug (en tout cas pas de debug local... je ne suis vraiment pas fan du debug distant). Ce mode de développement se voit bien complété par un serveur de build. Autrement dit, une meilleure maîtrise de l'intégration, mais moins de souplesse côté debug.