Automating WSS v3/MOSS 2007 development environment setup: Part I – Planning

Hello,

Recently, I advised customers on their development environments. Many different options are possible and each choice done brings benefits and limitations. In this post and few others to follow, I will discuss the main options, with their impacts, and then describe how to automate the setup of the developers’ environment, to insure the use of these choices in a consistent manner.

This first post discusses the different main options to baseline a development environment for SharePoint Products & Technologies.

When having a look at Microsoft guidance on MSDN, you find relevant contents:

1. Setting Up Development Environments for the 2007 Microsoft Office System (https://msdn.microsoft.com/en-us/library/bb330848.aspx): this article gives good information, but is NOT adapted to SharePoint development

 

2. SharePoint Team Based development (https://msdn.microsoft.com/en-us/library/bb428899.aspx) completed with
Development Tools and Techniques for Working with Code in Windows SharePoint Services 3.0 (https://msdn.microsoft.com/en-us/library/bb530302.aspx) Interesting to help team understand the process, the delivery packaging and which environment to setup. These articles are just completed by this one, released recently : Using Team Foundation Server to Develop Custom SharePoint Products and Technologies Applications. 

Additionnaly, a new MSDN highly valuable article is available on SharePoint Guidance, from the Patterns & Practices group. You'll find these informations here: https://www.microsoft.com/spg

As synthesis, I often go to these 2 main options presented to customers:

· Option 1 /Working Locally = Dedicated VM per developer + common hardware to support functional services (like SQL, Source Control, development domain ….)

 

· Option 2 /Working Remotely = 1 Physical server hosting development environment, and developers working through Terminal Server/RDP Client on the machine

Option 1 is adapted to most of developers’ needs, and customer’s situation (it’s the 90% of the recommended cases). My favorite option for sure.

Option 2 is adapted if hard security or few rights are allowed to the developer on its workstation. The main disadvantage of this option is the Memory need, as 1 development environment loaded could exceed more than 1.5 GB RAM need => 10 developers would need up to 15 GB of RAM on the server ? …. Any budget for this?

 

Now, that we talk of “Working Locally”, there is a lot of questions to be answered to setup the environment:

Question	Value	Comments
Base environment components	- Windows Server 2003 SP1 or higher - SQL Server 2005 SP2 or higher - WSS v3 SP1 + Infrastructure Update or - MOSS 2007 SP1 + Infrastructure Update - Language Packs needed - .Net Framework 3.0 SP1 or higher	Be sure to get SQL Server Management Studio (with SQL Profiler) to track data connection between SharePoint and SQL Server
Source Code Management system	- Team Foundation Server - Visual Source Safe - Any others	To use TFS, you’re not obliged to have dev machines in the same AD domain (but you’ll need to authenticate on the TFS server)
Virtualization	- For stand alone : almost always yes (dual boot is a burden) - For Team based: you should probably share components and put them in a physical environment. For example, you can dedicate a box to host the DC+SQL Server roles for the development team/domain	Be careful enabling Domain Controllers for “development” domains in an Enterprise managed network: don’t disturb the production domain, watch the DHCP server settings, etc ….
Development output	Use WSP packages!	More Info here: https://msdn.microsoft.com/en-us/library/cc441431.aspx
Development Core software	- Visual Studio 2005 + VSeWSS v1.1 + WWF extensions for VS 2005 or - Visual Studio 2008 + VSeWSS v1.2	VS 2005 SP1 is not mandatory VSeWSS stands for Visual Studio extensions for Windows SharePoint Services (can be found here)
Platform technology	x86 for sure !	Visual Studio is x86 only application and VSeWSS won’t install on x64 platforms. If deployed on x64 platform, the JIT will compile it on the fly (you must be careful of your project options in Visual Studio anyway)
Domain or Workgroup	That is the question! - If you plan LDAP use, user profiles tests/use, or spanned server roles on different machines you need Active Directory - If choosing Workgroup, everything on the same box is mandatory	For enterprise work, go for Active Directory (beware that Document Conversion don’t work if SharePoint is hosted on a DC !) For personal development, perhaps workgroup is enough, but you’ll miss the LDAP and User Profiles features. Most of my colleagues run with Domain dev environments. The Microsoft WSS v3 developer VHD runs in a Workgroup.
Office System software products	- Office Suite (a version that maps your user’s environment). Have special attention to InfoPath - SharePoint Designer 2007	Check what IT admins decided regarding the deployment of Office and SharePoint products (like SharePoint extensions)
SharePoint installation	Full is the best option (everything except SQL server)	Autonomous can be option: but it will setup SQL server express with a specific instance called OFFICESERVERS. But you won’t benefit the SQL tools like SQL Profiler and Management Studio. Once setup with this option, some parameters are locked in the farm so that you can’t change the SQL instance.
Additional Tools	- WSS v3 + MOSS 2007 SDKs - Fiddler2 - Notepad ++ - WSPBuilder (if needed see below) - Reflector - IE Dev Toolbar - Firefox + Firebug - SharePoint Manager - Codeplex projects - Microsoft Network Monitor - Any third party tools - Etc.	There are a lot of possible tools. Any developer its choice and habits. The list here is just ideas … Here is a Codeplex project that may help : SharePoint Visual Studio Project Templates
SharePoint development methodology	Help yourself and make your own opinion: - Ted Pattison method : https://www.codeplex.com/stsdev - Scott Hillier method : https://www.codeplex.com/SPDevMod - Andrew Connell method : https://www.andrewconnell.com/blog/archive/2007/08/21/6095.aspx - Any others you find or build J	You can read this interesting post from Scott on VSeWSS here : Is VSeWSS 1.2 Ready for Prime Time? This way of doing development is really up to you. The most important is the output = WSP files ….

 

That was a little journey in the great world of tools to develop on SharePoint. You may think its complex, and you’re right. Next release should ease this aspect as SharePoint development was understood to be too much complex. What will help: Visual Studio next version, or SharePoint Designer 14? Who knows?

In my next post, I’ll give you the description of the platform I use, and how to have it “up and running” an automated way.

Best Regards,

< Emmanuel />

UPDATED Links:

Being concious of issues creating and developing solutions on MOSS, Microsoft started this new MSDN section : SharePoint Guidance (https://msdn.microsoft.com/en-us/library/dd203468.aspx). This a very positive initiative.

You should especially have a look at this page : Creating a Development Environment (https://msdn.microsoft.com/en-us/library/dd239299.aspx) , even if it's very generic information.

Comments

• Anonymous
  April 17, 2009
  Hi, This long post series raised interest from many of you. Thanks for that. I was asked few times to

• Anonymous
  April 20, 2009
  Un petit post rapide pour linker une excellente série faite par Emmanuel Bergerat sur son blog : Automating

• Anonymous
  April 20, 2009
  Un petit post rapide pour linker une excellente série faite par Emmanuel Bergerat sur son blog : Automating