|
When doing development for SharePoint 2010, should we use a farm or a standalone setup? One difference is that the farm uses the full SQL Server while standalone employs a local SQL Express db. Our production environment is a farm but is the standalone setup sufficient for development? Your guidance is appreciated. Thanks. |
|||
|
|
|
The standalone setup is generally more than sufficient for development unless you are developing against SP2010 Enterprise only features.(as opposed to the base Foundation product). You will save yourself a TON of hassle by having Visual Studio 2010 and SharePoint installed on the same OS (e.g. F5 to compile, run and debug all in one go) rather than using separate servers (VM or otherwise) and performing the incantations required to get remote debugging working. Others have suggested that you need to setup your dev box with W2008R2 server - thats not necessary, it will work just fine with Windows 7 (x64) or even Vista. |
|||
|
|
|
Everyone seems to be saying the same thing, but I have one thing to add. Yes, a stand-alone environment is, I guess, sufficient for a development environment. However, for my set-up, I mimicked a stand-alone by choosing a farm installation, but installed everything on one machine. Why? By going down the default, stand-alone route, SQL Express is installed, and with that you have the limitations that come with it. Further, I recall from some of my research on the topic that there is no way to branch out to a farm environment from a the default, stand-alone installation. On the other hand, one very likely may never do that kind of migration in a dev environment, but I for one would never want to limit myself. |
|||
|
|
|
check this might help you to go into deep. |
|||
|
|
|
For your local development environment, a standalone server is a more effective use of resources. You can attach Visual Studio to your server more easily and there is much less configuration than a farm environment. A VM is usually the way to go. It is a good idea to have a test environment which reflects the architecture of production. This minimises any environment specific issues that arises. This is particularly useful for testing SharePoint updates - the process is slightly different for a multi-server farm. |
|||
|
|
|
I would strongly recommend creating a single server installation for your SharePoint 2010 development environment with full SQL Server so that your changes do not effect your production environment. Keep in mind that all of your production SharePoint servers run Windows Server 2008 x64. The best and easiest way to perform SharePoint development is directly on a SharePoint server (with matching platforms and patch levels as the production environment). You could also take the Content Databases from your production and attach them in you local/remote SharePoint development environments to have better overview, by testing customizations on real content. I prefer to have a local SharePoint virtual machine running on my desktop as I code and test with Visual Studio 2010. This way I can create the deployment files, test them on development and then to production. |
||||
|
|
|
We use a SharePoint standalone for Development, but then package and deploy our WSP's for testing in a Test environment that has an Admin, WFE and Search server (for 3 machines) just like Prod. The Development environment is simpler to manage and easy to deploy to and verify changes, but the Test environment helps to work out issues seen in Production. |
|||
|
|
