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 (http://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 (http://msdn.microsoft.com/en-us/library/bb428899.aspx) completed with
Development Tools and Techniques for Working with Code in Windows SharePoint Services 3.0 (
http://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: http://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: http://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 : http://www.codeplex.com/stsdev


       Scott Hillier method : http://www.codeplex.com/SPDevMod


       Andrew Connell method : http://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 (http://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 (http://msdn.microsoft.com/en-us/library/dd239299.aspx) , even if it’s very generic information.

Comments (3)

  1. Hi, This long post series raised interest from many of you. Thanks for that. I was asked few times to

  2. Un petit post rapide pour linker une excellente série faite par Emmanuel Bergerat sur son blog : Automating

  3. Un petit post rapide pour linker une excellente série faite par Emmanuel Bergerat sur son blog : Automating