views:

67

answers:

3

I would be interested to hear how people develop for moss.

We currently use virtual environments, with wspbuilder and nant scripts to build and deploy.

We are finding the debugging and deployment process slow for our devs.

Can anyone suggest ways to speed everything up?

A: 

The only way i know of is just attaching to the w3wp process. It is the only way I think. I have added some external tools shortcuts for deploying faster on my dev machine, but that's it.

Colin
It's the deployment that's taking the time we thing i.e. copy to GAC or copy to 12 Hive, that extra step.
78lro
A: 

What you're doing already is great. I'd look at it from the hardware perspective: RAM and hard disk.

SharePoint, Visual Studio and SQL Server (if on the same box) all like to gobble up as much RAM as possible. Make sure you're running with at least 2GB, if not 4GB.

Also, Scott Gu says to get the fastest possible hard-drive. SSDs are a great way to get significantly improved performance. It's a little tricky balancing the cost with drive size at the moment however.

Alex Angas
A: 

STSDEV!

Long gone are the days of manually copying assemblies to the GAC, deploying features, and syncing changes to the 12 hive.

STSDEV will create a new visual studio solution for your project which will include build configurations that automate the tedious process of deploying a solution.

There is a 'rootfiles' folder in the solution. This is where you add all files that you usually copy straight to the 12 hive. When you deploy, all of these files will be moved to their corresponding folders. (you match the folder structure within 'rootfiles' to the corresponding directories in the 12 hive).

It is all much simpler to use than it may sound. There's a few really good tutorials on the codeplex site, and after that, you should be good to go.

As far as debugging goes, once the deployment process is streamlined via the use of STSDEV, attaching to the w3wp.exe process to test code then redeploying is easy.

Thanks! We have nant scripts that run both locally and on check-in to our integration environment but still running this build/deploy while developing slows our devs down considerably
78lro