SharePoint Development in VM and Version Control With TFS

Our team is going to be developing against SharePoint using local VMs. Our VMs are not allowed to join the host domain. Additionally our host nics are prohibited from using Internet Connection Sharing. We have a requirement to source control all our development work using Team Foundation Server. Our TFS installation is using Kerebos for authentication.

To be able to use TFS for source control we were thinking we could share a folder between the host and VM, do our work on the VM, save to the shared folder and then do check ins and such from the host which will be able to authenticate against TFS.

I'm hoping there is a cleaner way to do this or someone with similar restrictions can provide some insight.

Note: I have successfully setup a similar mechanism using Tortoise SVN and Ank开发者_C百科h SVN that works, but management will not budge on the TFS requirement. Not that I blame them either, the license is very expensive and they want to feel they are getting their money's worth. Therefore TFS has to be included in the answer.

Here's a solution that works perfectly for SharePoint 2007 development.

We run virtualised instances of Windows Server 2008 on our Windows XP machines at the project i'm on. We use Sun VirtualBox as the virtualisation software.

secondly, each VM is a standalone domain controller + sql server + reporting server + analysis server + sharepoint server and as such isn't joined to the main domain.

when opening up Visual Studio 2008 and connecting to TFS you don't need the machine/server to be connected to the domain as the VM NATs through the host machines network adapters - use a fully qualified address for your TFS and you shouldn't have any problems connecting to TFS from within the VM.

you may need to turn off integrated windows authentication (IE -> Tools -> Internet Options -> Advanced)...

We also run VS08 in the VM and not on the host..

Another thing is to use WSPBuilder to build your solutions and create the deployment scripts for you (or alternatively just set up an external tool/command from VS08 that runs the stsadm.exe -o deploysolution command)..you can deploy effortlessly to the VM and ensure that it runs fine - then just check in your code, set up build scripts that fires off WSPBuilder on the build server to build the solutions for you and deploy from there (or copy the WSP up to the server and run them there).

I think your solutions is as clean as it will get.. you could map a folder on your host machine and open the Visual Studio project straight from there within the VM. Saves copying. Committing will have to be from the host. Use of TFS features will be a bit awkward, you'll have to open VS on your host machine as well to connect commits to work items etc. Not exactly what the investment in TFS was for. How come they've dished out the cash for TFS but are not willing to facilitate it? The VM's should really be in the domain.. or at least a trusted domain.

We run the same setup except we do have SVN and can commit directly from the VM. Workable :)

BTW, if you develop for SharePoint 2010 this gets better; it'll allow installation on non-server OS's so you can develop on your local machine (which I guess, is on the domain).

I generally use VS2008 running on the host with the SharePoint assemblies installed to the GAC of the host. I use build events/build targets with a shared folder and sysinternals to build directly to the SharePoint VM's bin/GAC folders. This way Visual Studio builds directly to the SharePoint server and you do not have to manage 2 installations (host and VM). I would also recommend installing VS2008 debugger as a service on the VM for easy debugging.

Hope this helps!