If you’re like me, you stay away from installing SharePoint on your client OS (Windows 7) and just put it on your server OS and run within a VM. However there are times you want to pop into Visual Studio without firing up a VM and exploring the code. Of course you can do that, but it gets tricky when you want to build or run unit tests.
One trick I use that works most of the time (not all the time) is to put the SharePoint assemblies on my machine and make my own SharePoint Root (aka “14 folder”) on my Windows 7 machine. It’s easy enough, but maybe you want to check the differences between different releases (RTM, SP1, CU’s, etc).
What I do is use PowerShell to extract all the DLL’s from the SharePoint Root folder and put them in a place I keep documentation, snippets, etc on my machine. For example, I’ll have a folder that looks like this:
c:\Dev\Ref\SharePoint\14 (4762.1000 - RTM)
I only include the DLL’s because the SharePoint Root is huge. For SharePoint 2010 RTM, just the DLLs are about 60MB. Ideally I’d like to grab all XML, WEBPART, ASPX, and ASCX files when I’m researching how something works, but that takes just a bit more time. Then I’ll go to the place where the SharePoint Root is when it’s installed and add a symbolic link that points to it like this (from an administrator command prompt):
c:\[Path to Web Server Extensions]]>mklink /d 14 “c:\Dev\Ref\SharePoint\14 (4762.1000 - RTM)”
Now when I navigate to the 14 folder I go to the same place where you find it on an installed machine, but it really lives somewhere else. If you want to switch to something like SP1, then you copy those same assemblies and recreate the 14 link to point to the new folder.
One day I’ll write some utility or PowerShell script to handle the deletion/creation of the symbolic link to the version I’m interested in. One last thing: this is *not* a replacement for testing your projects in a real deployment… it’s just a quick & dirty trick.comments powered by Disqus