blog.richardramdat.com

SharePoint Development

March 31st, 2009 › Development › richard ›

Today at work it was suggested that our SharePoint team (about 3 developers) use a single server on our network as our primary SharePoint development environment. That means all three developers will log on to the same server with different accounts, use Visual Studio and deploy to the same instance of SharePoint, all on the same box.

Those familar with SharePoint development will know that this is a recipe for diaster. Typically, development for SharePoint is done within an isolated Virtual PC and for good reason.

Unfortunately our Systems team got wind of our plans to host local virtuals running Windows Server with SharePoint and the idea was quickly killed as a violation of “policy” (apparently all servers should be managed by our system admin team, even those used exclusively for development).

So, if you find yourself in a similar situation and need ammunition as to why each developer should have an isolated environment, feel free to use the following:

Why Individual Development Environments?

Initial SharePoint development cannot be done on a shared server (with concurrent users) for the following reasons:

Global Assembly Cache (GAC) – SharePoint development often requires custom applications and libraries to be deployed to the GAC. If two or more developers are working on a class library that outputs a DLL with the same name, then deploying that DLL to the GAC will only include changes made by a single a developer. Multiple developers will not be able to keep track of current deployments by other developers or be able to test their individual changes.
Build & Compilation – Code compilation is an extremely processor intensive task that often requires 100-percent CPU utilization for the length of the compile. A developer is constantly recompiling code to test and debug, if multiple developers are sharing the same machine, then this would undoubtedly result in constant CPU usage and unusable system performance. Additionally the Visual Studio development environment is an extremely resource intensive application. It is not uncommon for a single instance of Visual Studio to use at least 500MB or to regularly drive high levels of CPU utilization.
Unreliable Server Availability – Deploying code often requires IIS services and application pools to be recycled or restarted. In a shared development environment with multiple developers it will be unfeasible for a single developer to effectively test changes or debug problems if other developers could be causing application errors by restarting system services.

Microsoft’s Recommendations:

“Most SharePoint developers use a local SharePoint installation. This allows them to build, test, and debug their work without affecting the work of anyone else on the team. The local environment can be installed on either the developer’s host workstation or on a virtual computer that runs on either Microsoft Virtual PC 2007 or Microsoft Virtual Server 2005 R2.”
(http://msdn.microsoft.com/en-us/library/dd239299.aspx)
“When each developer has her own instance of SQL Server 2005 and Office SharePoint Server 2007 or Windows SharePoint Services 3.0, this configuration helps prevent conflicts during development, mitigates performance issues during debugging, and ensures that the solution works in multiple environments.”
(http://msdn.microsoft.com/en-us/library/bb330848.aspx)
“First and foremost, you need to develop locally for the “best” debugging and testing experience. Development is done in a virtual machine using the Win2003 OS and WSS/MOSS installed. Each developer should have their own virtualized environment…”
(http://blogs.msdn.com/scaravajal/archive/2008/04/27/creating-a-sharepoint-development-environment.aspx)
“Working locally…you can configure the development environment so that all of the SharePoint development work can be done locally…We recommend this configuration for a number of reasons…”
(http://msdn.microsoft.com/en-us/library/bb530302.aspx)

SharePoint Development

Archives

Meta