SharePoint Web Parts Development Environment

I know there are so many questions and articles on this topic and I have searched hours and hours on the Internet so far, but I still couldn’t find the right answer for my question. I was assigned the task to investigate the development environment for SharePoint web parts by my company. The money is not an issue but it must be the proper way to do it.

Here is my ideal plan: at developer desktop, install VS2005/2008 (it is already installed), VS2005/2008 Extension for SharePoint and WSPBuilder. It is also installed a Virtual Machine and the VM runs windows server 2003/2008. WSS3.0 and SQL Express 2005/2008 will be also installed on VM.

Developer’s desktop is a web parts development environment. Developers use VS to develop the SharePoint web parts and then run the WSPBuilder, it will deploy the web parts into the SharePoint testing environment on VM. So the VM is just a SharePoint testing environment. It looks like a good idea, however, it doesn’t wor开发者_JS百科k. Why? Because VS extension can't be installed on developer’s desktop as it doesn’t have WSS3.0 installed!

I definitely don’t want to install the VS on the VM, because our developer desktop has installed VS and we don’t need to have 2 VS licences for 1 developer. Any idea what is the best way to set up the development environment for SharePoint web parts?

Thank you in advance.

You won't be able to develop for SharePoint (WSS 3.0) unless your development environment includes an installation of at least WSS. In general, development is done on a Windows Server 2003 Virtual Machine (Visual Studio is installed directly on this machine). However, SharePoint can be installed on Windows Vista and Windows 7 machines, so your development machine may be able to host SharePoint itself, but it is far easier to do this on a VM.

My SharePoint development VM has the following installed:

• Windows Server 2003 R2
• SharePoint 2007 (Including SQL 2005)
• Visual Studio 2008
• Visual Studio Tools for Office
• Office Server SDK
• Visual Studio Extensions for WSS 1.3

Obviously you can use WSPBuilder instead, but I much prefer VSSWSS 1.3, but that is developer preference.

I believe (should be verified with Microsoft) that the licensing for Visual Studio can be extended to Virtual Machines when used by the same developer (depending on your agreement).

An alternative for you which may or may not work depending on your priorities.

Install Visual Studio 2010 and SharePoint 2010 Foundation to your development server.

Grab a copy of Microsoft.SharePoint.dll from a SharePoint 2007 server.

Use VS2010's tools to develop a web part but manually change the reference to the 2007 dll's (+ also see "Build a SharePoint 2007 Web Part with a Visual Studio 2010 Visual Web Part Project") so you are outputing a 2007 compatible web part.

When you delploy your 2007 web part to your local 2010 server it will just work (as its backwardly compatible)

When you deploy your 2007 web part to your test/qa/production servers it will work too.

Advantages

• You're working with latest greatest version of VS and the sharepoint tooling so you get one click deploy, automatic creation of WSP packages etc. Nothing against WSP Builder etc (they are great) but my moneys on vs2010 sharepoint extensions for the future.
• You're ready if/when your company moves to 2010.
• You're developing on a Windows 7 machine, not a 2003/2008 server and or a VM so this has advantages for licensing, speed and ease of use (dual monitor support from VS running on a VM?)

Edit - to deploy web parts to other servers you create a .wsp package and then deploy via STSSADM or another tool (SharePoint solution installer or other admin tools).

I haven't used VSSWSS or WSPBuilder. I've always used STSDEV for SharePoint 2007. And I've always used Windows XP to do it. I don't know if VSSWSS and WSPBuilder act the same, but, as Ryan was saying, I copy whatever SharePoint DLLs I need from a SharePoint 2007 server into a Solution Folder in my Visual Studio solution. I then select Add Reference in my project and browse to the DLL.

In four years, I've never had any problems with this method. The solution packages build just fine and work on any SharePoint server. I lose the option to debug, but I'd rather stay on my machine than go into a VM or Remote Desktop.