Tom Clarkson is a SharePoint consultant and entrepreneur based in Sydney, Australia.

Contact Details

Links



Recent Searches



Archives




Past Posts







RSS Feed

Thoughts on Running SharePoint Without a VM

SharePoint 2007, Thoughts on Development
Sunday May 25 2008

While randomly looking through the incoming searches on my blog, I came across a post from Bamboo Solutions - How to install Windows SharePoint Services 3.0 SP1 on Vista. Hacking the installer to allow SharePoint development without building a VM is something I've had sitting on my list of stuff to try out for about six months, so it's good to see someone has put the solution out there.

   

Removing the VM requirement is a fairly important part of making SharePoint development easier. Visual Studio is really painful to use if you have to go through remote desktop, and even running locally with Virtual PC has its little issues like not being able to bring up intellisense with alt-right.

   

Being able to install SharePoint locally is certainly a step in the right direction. I've had all sorts of issues with things like virtual machines not being approved to connect to the network and therefore being unable to use source control or backup properly. Of course, in that sort of environment Vista probably isn't SOE either, but it could make things easier.

   

However, it's not a perfect solution, mainly in how easy it is to completely screw up a SharePoint installation. Despite the issues with performance and running visual studio, a virtual environment does have a big advantage in being easy to restore to a previous state.

   

When I'm next working on SharePoint development tools (which may be a while with all the other projects I'm working on at the moment), I'll probably go with a hybrid approach - SharePoint running on a VM and Visual Studio running natively. I have done this before in a limited way, setting up a web service that deploys an uploaded WSP file and calling it from a piece of the WSPBuilder add-in that hasn't made it into the official codebase as yet. The main piece of work left to make that system really workable is setting up the remote debugger.

   

More recently I have been thinking of another approach that may work better - setting up a continuous integration server alongside SharePoint. It shouldn't be too hard to make WSPBuilder run as part of the build script, and may actually make a shared development server workable.

3 Comments

Comments

On 25 May 2008 10:21, Brian said: 
Maybe you could change the alt-right key so that it isn't used for the vm.
On 01 Jun 2008 03:13, Peter Seale said: 
I'd be fascinated to hear what you come up with on the "build server" front. I'm also incredibly annoyed by the long deployment times--though I did attend a session by Alex Holcombe in Austin (no blog) and he mentioned his team got a HUGE performance boost by bypassing stsadm and using the deployment API directly in code. Something like "deploying 80 features went from 1 hour to 3 minutes". Yes, 80, not a typo.
On 02 Jun 2008 02:17, Tom Clarkson said: 
@Brian - True, though I do prefer to avoid using settings that I forget about every time I use a new machine.

@Peter - I'm not sure when I'll next get a clean slate to work on the build server idea, but given the code I have so far I'm convinced it will work quite nicely. I'm not surprised by the performance increase in using custom deployment - a lot of time probably goes into resetting IIS and the timer job stuff.

Leave a comment