Is SharePoint 2010 Server mandatory on Developers workstation?

Question

I have been a Developer during the Classic VB/ASP days. I remember that we used have Client Tools (Visual Studio, SQL Enterprise Manager) on Developers Desktop and there used to be seperate high-end Common Server for IIS/SQL, which developers used to connect. The developers used to develop code on their Visual Studio(Developer Workstation) and deploy it on IIS Server(Server-Based Hardware) for testing.

How can we have similar Setup in SharePoint 2010 Development. If there is a Team of SharePoint Developers, do they need to have SharePoint Server/Foundation installed on their individual Local Systems? Can't they make use of a central Single SharePoint Server in the environment to deploy their code and test it?

Please throw some light on this setup, as the Microsoft Site also talks on installing SP2010 on Developer PC. I have yet to find an article which discuss the above scenario.

After going through the Microsoft site articles, it looks like that SharePoint 2010 Developers cannot use Windows XP Operating System!

Answer 1

In SharePoint 2007 there was no choice (unless you consider this hack) but to install SharePoint on a server and make that your development environment.

I wasn't too happy with this in the beginning, but it made sense as your development environment and OS would mirror the Test and Production environments more closely. The way that many developers dealt with this was to create either a local or remote VM with Windows Server and SharePoint 2007 installed in it as well as Visual Studio and other development tools.

SharePoint 2010 officially supports the local installation of SharePoint on Vista X64 and WIndows 7 X64. However, I don't recommend going down this route if you can help it as I personally think, in case of SharePoint development, that it is better to develop in the same kind of environment as your Test and Production systems.

I believe the article you are referring to is for the beta of SharePoint 2010. The up to date version is Setting Up the Development Environment for SharePoint 2010 on Windows Vista, Windows 7, and Windows Server 2008.

BTW, have a look at our SharePoint Development Guidelines. It has not yet been updated for SharePoint 2010, but much of it applies to all versions of SharePoint. If you are new to SP Development then there may be some useful information in it.

Answer 2

I don't agree with Muhimbi about SPF2010 on Windows 7/Vista. I think it is great (used it for WSS 3 also). It makes me easy and fast to spin up new projects without VM's. Of course projects never goes from the dev workstation to production directly. You need to test it on a production-like server.

Having SPF2010 on a Windows 7 machine not only makes me work faster, it allows me to save power (battery), disk and a lot of other things (read my post about it here). Since running a SP2010 VM requires you to have some good HW a local Win7 installation makes you jump on the SP2010 bandwagon quite fast.

Answer 3

I used to work at a company where we developed everything on our local machines running Windows XP without SharePoint installed. We deployed to a development server running SharePoint 2007 that we shared (between two people) and used Visual Studio remote debugging against it. The experience was often frustrating, and the arguments do not change for SharePoint 2010.

1. Only one person could debug at a time.

2. We had to open up ports on the firewall to enable remote debugging.

3. Remote debugging wasn't as reliable as local debugging. For example, timeouts were more frequent.

4. Testing dev code meant building a solution package then copying it over and deploying it. Or we copied over the DLLs and other things that are changed. It was fiddly and time consuming as we couldn't use tooling such as WSPBuilder to right-click and deploy locally.

5. It was tempting for developers to deploy something to the server, fix something in an XML or CSS file there, then forget to copy it back into the solution package. This made for unreliable deployments and artifacts out-of-date or missing from source control.

Regarding installing on top of Windows 7, it's my personal preference not to do so. I like having my development environment in a separated virtual machine. It means my host machine has less software installed and is therefore less prone to problems. Also backup and restore is easier because the entire VM can be copied over to an external drive. There's other reasons to be found on this page and elsewhere on the Internet. :-)

Answer 4

When I developed on MS Sharepoint Server 2010 machine, intially I naively downloaded 64 bit version of Sharepoint Designer 2010 which setup told me to download (again) SPD 2101 32 bit b/c my machine had 32-bit version of Microsoft Office 2010 installed.

And the latter, i.e. 32-bit version of Office 2010 is, AFAIK, recommended for use with Sharepoint Server 2010.

So, one can, I still hope and believe, develop in SPD2010 32-bit and Infopath Designer 2010 32-bit

I am currently develop accessing Office 365 (Sharepoint 2010 Online), Plan E3, trial from 32-bit Windows XP SP3 using:

• 32-bit versions of Microsoft Sharepoint Designer 2010,
• Microsoft Infopath 2010, 32 bit (x86)
• browsers (IE8, Mozilla Firefox, Google chrome).

So, when I insert a web part, including those configured/developed with my local 32-bit Infopath Designer 2010, SPD 2010 or browsers, it is not my local machine that compiles them. They are compiled and come from remote Microsoft Sharepoint Server 2010.

Anyway, I opened a thread What cannot be developed for Sharepoint Server 2010 in 32-bit workstation? and in 64-bit workstation?

Update:
The given above link was not the question whether it is possible to develop on workstation without Sharepoint Server 2010.

I am developing on Windows XP SP3 32-bit machine against Microsoft Sharepoint Server 2010 (Sharepoint Online, Office 365).
It was rather a call for a feedback to share with first-hand experience. possible pitfalls and workarounds. I feel I rather lost my time for writing it having gotten there the out of any real life or work theoretizations about impossibility of what I am in fact doing.

Let me remind that when I insert a (sharepoint) web part into a web page and configure it, it is not compiled or run by my local workstation but by the remote Sharepoint Server 2010.