A major limitation of developing against SharePoint is that Visual Studio must be on the same machine as a SharePoint Server instance.
After a brief experiment with some methods involving copying the collection of SharePoint .DLL’s to the GAC on your dev machine and referencing them Visual Studio Projects – I can confirm why there is general silence on MSDN when people gripe and ask why you need to burden your dev machine with a SharePoint server – because that’s just how it is if you want to develop effectively.
So until MS comes up with a way to allow Visual Studio to connect to remote SharePoint servers, we will be stuck with having to either plug Visual Studio into the dev servers we stand up, or install Visual Studio on our main dev workstations.
Although workstations are generally pretty juiced up these days, performance is an issue trying to run all those servers at once, so it’s looking like working on RDP with the dev workstation experience set up will be the best compromise.
To this end, we can try and remove a lot of the annoyances that come with using Windows Server 2k by making them behave more like desktop workstations. A basic laundry list is as follows:
a. Remove the shutdown tracker
b. Give the machine an intuitive name
c. Remove and disable screen saver
d. Install Desktop Experience
e. Enable graphics acceleration and sound
f. Enable RDP
g. Disable Internet Explorer Enhanced Configuration
h. Install other browsers and associated cool plugins (Firefox for example)
i. Full update and patch using Windows Update (duh!)
IF you want to go further and get more Win7 glory, check out this handy tool for making your Win2k server business on top but rock steady on the sides: