views:

219

answers:

3

First, let me use one sentence to let out some frustration: My god, developing for SharePoint is a f-ing mess!

OK, sorry, let me focus in on 1 specific scenario. I've developed (VS2005) some functionality that works if I deploy it as a DLL on a SharePoint (MOSS2007) server. Now I'm trying to identify the best way to package it as a deployable Feature.

Based on search results, you'd think no one has ever successfully done this in a repeatable manner! Each article contradicts the next, or documents a technique that patches some problem with someone else's techniques, and in turn is probably updated in yet another article. Many seem based on legacy methods for 2003, WSS, etc. Some recommend using MSBuild tasks to deploy to your code, copying files manually into directories with names like "12", or using tools like SharePoint Designer or to make modifications directly to a server. These sound like hacks that developers would use to install on a test server. Has anyone ever created a project that, after a successful build, can be taken to another machine and deployed with an installer or single command line instruction via STSADM?

I admit that I only have a beginner's knowledge of SharePoint administration, but it must be easier than it seems. I think I understand the basic concepts at http://msdn.microsoft.com/en-us/library/ms413687.aspx but isn't there a way to automate that? There must be one recommended practice for packaging features to be deployed on a 2007 server.. but for the life of me I can't figure out which one it is. (My best guess is that it's something like this: http://www.codeplex.com/sptemplateland, but that hasn't been updated since Feb 2007.)

Can anyone help? Thanks so much!

+7  A: 

Hello,

The 'talk on the street' usually revolves around three options for SharePoint development.

  1. VSeWSS, Microsoft's own extentions for Visual Studio.
  2. STSDEV, pre-creates a VS solution based on your specs
  3. WSPBuilder, my preference because of its VS integration

All have strengths and weaknesses and I advice you to try out all three to find your preference.

.b

Bjørn Furuknap
Thanks, I'll give WSPBuilder and STSDEV a try! Will be back to pick the "correct" answer based on what I find :)
Steve Eisner
WSPBuilder is the ways forward for building features. Having said that, as soon as you are wanting to do more complicated features, you'll soon end up knee-deep in XML..
marcus.greasly
+3  A: 

Having used VSeWSS 1.2 I would recommend creating an STSDEV solution that wraps up the code and copies the webpart to the correct place.

Update However, VSeWSS 1.3 is now the "official" MS take on things and will be supported in future versions of Visual Studio, so that is probably the route to take now.

Unfortunately you are still going to need to know where every thing has to fit go into SharePoint to get it to work. Under the hood, the solution and the feature still use gnarly XML formats to control the direction all the bits of the solution go.

After a while the acute pain you feels dulls to a low throb.

Nat
Thanks, I'll give STSDEV a try! Will be back to pick the "correct" answer based on what I find :)And good to hear that it gets easier. I'm really in need of some aspirin for this SharePoint pain
Steve Eisner
A: 

Will anyone recommend VSeWSS 1.2 (for VS 2005)? How can we set that up in source safe and have multiple developers work on it?

dirq
VSeWSS and SourceSafe? Ouch.
Alex Angas