Développement SharePoint dans VM et contrôle de version avec TFS

Question

Notre équipe va se développer contre SharePoint en utilisant des machines virtuelles locales. Nos machines virtuelles ne sont pas autorisées à rejoindre le domaine hôte. De plus, il est interdit à nos hôtes d'utiliser le Partage de connexion Internet. Nous avons l'obligation de contrôler à la source tout notre travail de développement en utilisant Team Foundation Server. Notre installation TFS utilise Kerebos pour l'authentification. Pour pouvoir utiliser TFS pour le contrôle de la source, nous pensions pouvoir partager un dossier entre l'hôte et la machine virtuelle, faire notre travail sur la machine virtuelle, sauvegarder dans le dossier partagé, puis faire des vérifications et autres depuis l'hôte. sera en mesure de s'authentifier auprès de TFS. Je souhaite qu'il y ait une manière plus propre de faire ceci ou quelqu'un avec les restrictions semblables peut fournir quelques perspicacités.

Remarque: J'ai réussi à configurer un mécanisme similaire en utilisant Tortoise SVN et Ankh SVN qui fonctionne, mais la gestion ne bougera pas sur les exigences TFS. Ce n'est pas que je les blâme non plus, la licence est très chère et ils veulent sentir qu'ils en ont pour leur argent. Par conséquent, TFS doit être inclus dans la réponse.

Answer 1

Je pense que vos solutions sont aussi propres que possible. Vous pouvez mapper un dossier sur votre machine hôte et ouvrir le projet Visual Studio directement depuis la machine virtuelle. Enregistre la copie. L'engagement devra provenir de l'hôte. L'utilisation des fonctionnalités TFS sera un peu compliquée, vous devrez également ouvrir VS sur votre machine hôte pour connecter les validations aux éléments de travail, etc. Pas exactement à quoi servait l'investissement dans TFS. Comment se fait-il qu'ils aient donné l'argent nécessaire à la TFS, mais ne sont pas prêts à le faciliter? La VM devrait vraiment être dans le domaine .. ou au moins un domaine de confiance.

Nous exécutons la même configuration, sauf que nous avons SVN et pouvez valider directement à partir de la machine virtuelle. Travaillable :)

BTW, si vous développez pour SharePoint 2010 cela va mieux; il va permettre l'installation sur des systèmes d'exploitation non-serveurs afin que vous puissiez développer sur votre machine locale (qui je suppose, est sur le domaine).

Answer 2

J'utilise généralement VS2008 sur l'hôte avec les assemblys SharePoint installés sur le GAC de l'hôte. J'utilise des événements de génération/des cibles de construction avec un dossier partagé et des sysinternals pour construire directement dans les dossiers bin/GAC de la machine virtuelle SharePoint. De cette façon, Visual Studio crée directement sur le serveur SharePoint et vous n'avez pas à gérer 2 installations (hôte et machine virtuelle). Je recommande également d'installer le débogueur VS2008 en tant que service sur la machine virtuelle pour faciliter le débogage.

Espérons que cela aide!

Answer 3

Voici une solution qui fonctionne parfaitement pour le développement de SharePoint 2007.

Nous exécutons des instances virtualisées de Windows Server 2008 sur nos machines Windows XP sur le projet où je suis. Nous utilisons Sun VirtualBox comme logiciel de virtualisation. Deuxièmement, chaque machine virtuelle est un serveur de contrôle de domaine autonome + serveur SQL + serveur de rapports + serveur d'analyse + serveur de partage et, en tant que tel, n'est pas joint au domaine principal. Lors de l'ouverture de Visual Studio 2008 et de la connexion à TFS, vous n'avez pas besoin que la machine/le serveur soit connecté au domaine en tant que NAT VM via les cartes réseau des machines hôtes - utilisez une adresse complète pour votre TFS et vous ne devrait avoir aucun problème à se connecter à TFS à partir de la machine virtuelle.

vous devrez peut-être désactiver l'authentification intégrée des fenêtres (IE -> Outils -> Options Internet -> Avancé) ...

Nous courons également VS08 dans la machine virtuelle et non sur l'hôte ..

Une autre chose est d'utiliser WSPBuilder pour construire vos solutions et créer les scripts de déploiement pour vous (ou bien tout simplement mettre en place un outil/commande externe à partir de VS08 qui exécute la commande stsadm.exe -o deploysolution) .. vous pouvez déployer sans effort sur la machine virtuelle et vous assurer qu'elle s'exécute correctement, puis archivez votre code, configurez les scripts de build qui se déclenchent WSPBuilder sur le serveur de génération pour construire les solutions pour vous et déployer à partir de là (ou copier le WSP sur le serveur et les exécuter là).