About a year and a half ago, our petition at my current work site to create/use developer environments for SharePoint (then 2003) was punted, mostly because the requirements for dev environments are almost completely diametrically opposed to the various security and systems policies at this site. The detente when finally reached was that we could run entirely self-contained VPCs but only if they ran on our (my consulting company’s) hardware and were composed of developer licensed software licensed to my company.
Anyhow, now that 2007’s out, deployed at my current work site, and people are taking seriously the task of converting from MS CMS 2002 to MS SharePoint 2007, among other things, the need for developer environments cannot be denied, and the VPCs my company is creating for such an environment are too resource-intensive to run on our old laptops, so something’s got to give.
As such, I’m doing a lot of research about it to justify/position the arguments for such environments. In general I will have at least skimmed these links, but may not have read them thoroughly. These link dump posts are really something I do to keep track of my current research and provide pointers to those who might need them.
Basic assumptions:
- You want one server context (IIS/SharePoint) per developer for the initial code-writing steps
This is for non-shared resources, like web parts, maybe features, etc. Something that a single developer could conceivably do in a short chunk of time in the project.
The reason is primarily that when you attach VS 2005 to a dll/process during interactive debugging, the step-through operations lock up that application pool for anyone else sharing the same execution context. - Your basic virtual machine for this kind of dev work is going to be running Windows Server 2003, Windows SharePoint Services 3.0 and Visual Studio 2005, at minimum.
In our situation we’ll probably need the whole shooting match, because unapproved SQL servers are not allowed on the open net, and they’re unapproved if they’re not solely administrated by our DBA group. Similar injunctions apply to domain controllers and unapproved DC/AD activity, as well as simply running Windows Server 2003 on a non-server box. - If you are allowed to run the server type applications on the VPC and then use your host operating system (i.e. the Windows XP or whatever you’re running VPC in) to run the client developer tools against the services on the VPC, the actual recommendation is to do that instead
So you’d have a standard VPC image that has Server 2003, SQL Server (unless you’re sharing that as a network resource hosted somewhere else – but be sure you have the permissions you need to noodle around in it if it is a shared resource), AD (same cautions apply to this as SQL Server), and WSS3.0/MOSS 2007. You’d run this in a host operating system where you’d run all your client development tools. You’d still have one execution environment per developer, but the performance might be a little better.
Anyhow, here’s a list of relevant blog entries/MSDN/Technet articles:
- MSDN: Setting Up a Development Environment for the 2007 Microsoft Office System (2/2007)
- Eli Robillard’s World of Blog: How to Build a SharePoint Development Machine (2/23/2007)
- The .NET Addict’s Blog: Setting up your SharePoint 2007 Development Environment (1/9/2007)
- Virtual Generations: How to Build a SharePoint Development Machine (2/24/2007)
- MSDN: Conduct Team-Based Development of Windows SharePoint Services and SharePoint Portal Server Applications (for WSS2.0/SPS2003 – 11/2005)
Some links also for software architecture/development approaches:
- Chris Johnson’s MSDN Blog: Application Development on MOSS 2007 & WSS V3 (9/5/2006)
And some links to relevant tools:
- Todd Baginski’s SharePoint 2003 and MOSS 2007 Blog: Making development easier with the SharePoint Feature Manager (6/16/2006)
I’ll add more links as I ID them.