VSeWSS vs WSPBuilder vs STSDEV per WSS 3.0 / SharePoint sviluppo 2007

Question

Quali sono i tuoi esperienze personali con l'utilizzo di questi strumenti?

ho provato VSeWSS quando è uscito prima ed è stato frustrato da essa. Ogni nuova versione è stato lo stesso per me, ma per motivi diversi.

WSPBuilder notevolmente appello perché ho potuto vedere chiaramente dove i miei file sono stati dispiegati sul server. Il suo uso di riflessione per creare file CAS e il confezionamento di PSA è stato grande, così come i modelli di avviamento che fornisce.

Recentemente qualcuno mi ha segnalato in direzione di STSDEV. So che questo strumento è stato in giro per molto tempo, ma so molto poco su di esso.

Dalla vostra esperienza, che consiglierebbe e come sei arrivato a questa decisione

Answer 1

Ho costruito centinaia di soluzioni e web part utilizzando tutti gli strumenti là fuori (tra cui rotazione mia da zero). WSP è il migliore IMHO strumento per quello che faccio.

E 'a basso attrito per iniziare (ottenere il Visual Studio add-in!) E consente di ottenere rapidamente una parte web / caratteristica attivo e funzionante immediatamente. Poi si può lavorare la vostra soluzione e fare un one-click implementare in fase di sviluppo, allora imballaggio è necessario utilizzare facilmente (utilizzando lo strumento da riga di comando e qualcosa come NAnt / MSBuild) per la consegna ad un ambiente di staging / produzione. A differenza di STSDEV (che richiede obiettivi generazione personalizzata) o VSeWSS (che richiede di strutturare il codice in un certo modo) che cerchiamo di farmi lavorare il modo in cui voglio ed è adattabile e flessibile.

VSeWSS è bello nel fatto che si può usare ingegnere qualcosa di simile a un sito creato file stp in file di origine (ad esempio, i fab-40 modelli di applicazioni) che è utile è inversa ma questa è l'unica ragione per cui sarebbe noi.

STSDEV è bello, ma ci si sente a disagio e tende a ricostruire completamente tutto ciò che ogni compilazione (cioè la generazione DDF). Mi ha anche forze in una certa struttura e l'ultima volta che ho controllato che ci sono stati problemi con più parti web in una singola caratteristica, ecc E poteva andare meglio ma WSPBuilder mi dà quello che mi serve oggi.

Answer 2

WSPBuilder è la scelta per me, vi dà così tanto per libero durante lo sviluppo e una grande integrazione con Visual Studio. Ci sono un sacco di gemme nascoste in WSPBuilder, che si dimentica facilmente, come grande generazione automatica CAS. Do lettura Tobias Zimmergrens post su come iniziare con esso: http://www.zimmergren.net/archive/2009/04/08/wspbuilder-walkthrough-of-the-visual-studio-add-in.aspx

/ WW

Answer 3

Una cosa che vorrei aggiungere è che se un inizio, cercare di non passare direttamente nell'utilizzo di questi strumenti. Cercate di imparare a creare un WSP a mano prima. Che vi darà un gran lunga migliore comprensione su come questi strumenti sono pensati per il lavoro e il modo in cui l'aiuto. Essa vi darà anche una comprensione di cosa cercare se c'è un problema con un WSP creato da uno degli strumenti.

Answer 4

Io uso WSPBuilder (con il VS 2008 add-in) in combinazione con un modello di progetto personalizzato posso sviluppare una web part di lavoro e distribuire questo nel mio ambiente dev in circa 2 minuti!

Per i pacchetti soluzione single con uno-uno rapporto complessi (che è progetti più piccole dimensioni) questo è soddisfacente.

Proprio di recente ha avuto un po 'di problemi con un progetto più ampio con i riferimenti di assemblaggio mutliple , ma sono sicuro che sono io non impostando il tutto a destra piuttosto che un problema con lo strumento per-sé.

VSeWSS era goffo e imbarazzante ultima volta che ho usato e la sua mi ha messo fuori di riprovare. SP 2010 sembra che potrebbe imporve su questo in modo io probabilmente rivisitare di nuovo.

STSDev è qualcosa che non ho provato molto perché WSPBuilder ha soddisfatto le mie esigenze finora.

'Copy to GAC' e 'Copia a 12 Hive' caratteristiche sono sviluppatore cielo!

Answer 5

Sono sicuramente un fan di WSPBuilder, mi piace la struttura troppo ma i 1.3 modelli VSeWSS guardo un mucchio migliore rispetto alle versioni precedenti. Penso che se stavo iniziando dev ora mi piacerebbe prendere in considerazione prima di loro e non aver bisogno WSPBuilder, sarà insteresting per vedere se questo è il caso con il 2010.

Answer 6

WSPBuilder è il mio attuale strumento di scelta, credo VSeWSS è utile per le persone che iniziano fuori per l'uso in una configurazione cava di sabbia, ma una volta che si entra in progetti reali ha limitazioni e solo pelli troppo lontano da te.

Inoltre ho ancora utilizzare il buon vecchio eventi post costruire moda per la velocità.

Answer 7

WSPBuilder può spegnere una soluzione, funzione e parte web in meno di 30 secondi, mentre prima potrebbe richiedere fino a un'ora. Enorme risparmio sui tempi di sviluppo, mantiene concentrati sulla funzionalità si sta cercando di produrre e ci sono alcune caratteristiche di distribuzione fresco. L'altra cosa sta usando WSPBuilder in combinazione con SharePoint Solution Installer consente di generare un WSP che essere può essere installato tramite un file Setup.exe wizardy. Non toccare mai STSADM. E! È anche possibile configurarlo per attivare automaticamente funzioni al momento dell'installazione semplicemente aggiungendo un singolo come per il file di configurazione. Me ne sono innamorato e lo consiglio a tutti i miei peeps SharePoint.

Answer 8

STSDEV è la mia opzione. Ho costruire più di 30 soluzioni personalizzate di SharePoint che coinvolgono i gestori di eventi, wf, web part personalizzate, pagine di applicazioni personalizzate e sono molto soddisfatto con STSDEV. Una ragione è che tutto è trasparente, è possibile vedere i comandi STSADM in windiw uscita ed è possibile eseguire in un secondo momento sul server di produzione. E sì ..stay lontano dal VSeWSS è il peggiore.

Answer 9

Sono un grande fan di VSeWSS 1.3 marzo CTP, ma non è perfetto. Questa versione di VSeWSS sembra seguire le regole di SharePoint Devlopment meglio rispetto alle versioni precedenti.

I maggiori problemi che ho notato con VSeWSS è ...

1. Quando si sviluppa una parte web e fissaggio e controllo .ascx alla parte web per la visualizzazione, ho notato che quando si tenta di andare in progettazione o Split visualizzare vedrete gli errori. È possibile aggirare questo copiando il file ascx alla radice del progetto, aprire il file ascx, e spostarlo di nuovo al vostro posizione corretta nel progetto. Penso che questo è più di un problema di Visual Studio 2008.

2. Quando si lavora con le caratteristiche non si scherza con gli ID di funzionalità. Si fa qualche male ... Come si fa a cambiare una caratteristica id in un progetto VSeWSS ... Non sono sicuro, penso che la sua magia nera.

3. Se si sta creando una definizione di sito in VSeWSS 1.3 CTP è necessario assicurarsi che escludere la cartella pkg dal progetto durante la distribuzione altrimenti si poteva vedere e messaggio di errore. Quindi, prima che io possa controllare il mio codice INT ho bisogno di includere la parte posteriore della cartella PKG nel mio progetto e quindi escludo che quando lavoro sul agian progetto. Che dolore!

Se c'è qualcosa che ho imparato su VSeWSS è non si scherza con la cartella pkg e di utilizzare invece la vista WSP. A parte questi problemi minori, VSeWSS 1.3 CTP è stato grande! Ricordate il suo solo un comminity Technology Preview (CTP) e dovremmo vedere la versione Release To Web (RTW) molto presto.

Answer 10

I used WSPBuilder since the early releases where it was just a console app. For a period i used STSDEV, but after seeing what Keutmann has done with VS integration and all, im growing really fond of WSPBuilder again.

Sure it has its quirks (like adding all worker processes when debugging, re-building up to date solutions before building WSP file, OOTB templates using old webpart namespace, inability to add assemblies to wsp packages if file is in GAC etc) but for a guy like me that works with SharePoint in Visual Studio every day, its a great tool that makes me blissfully ignorant of DDF files and pesky manifest files (and yes i do advocate that you first build your first 100 WSP files manually so that you know what goes on behind the hood, but after that its just a nuisance).

On the downside WSPBuilder documentation is non existing and you have to rely on Codeplex forum or blog posts like the recent one by Zimmergren that Wictor mentions. Hence im sure lots of the above quirks can be configured away, but it takes alot of digging to find out how (like you have to know that if you want to deploy assemblies in same project to both GAC and BIN you need to have folders called GAC and 80/bin in root of project, and not configure anything in wspbuilder.config.exe)

I do use VSeWSS 1.3 but only for extracting site or list manifests (i do this less and less btw since theres lots of nice STSADM extensions out there that does a better job than VSeWSS).

What im extremely curious about, is how the OOTB VS tools for Rosario and 2010 will be. Nightmare scenario would be a VSeWSS 1.something...

STSDEV is good, but limits my freedom of doing "business as usual" in VS. Also i cant remember when it was updated last time...

[edit: im not an expert in these things, but isnt questions like this normally marked as community wiki?]

Answer 11

Don't forget the SPDevWiki link on this one also.

My preference is WSPBuilder. I did try again at VSeWSS 1.3 CTP but the poor support with source control pushed me away.

Answer 12

The best tool? Use SPVisualDev. It leverages the power of wspbuilder and adds some fantastic instant debugging and deployment tools. It also has a intuitive way of adding features to a solution and you can configure the environment to your liking, including specifying wspbuilder params, such as custom cas policies.

Answer 13

I think VseWss has long way to go it is not ready to be used because it should first follow the architecture of SharePoint to be good deployment too for example : you can create list definition using the template provided for that list definition you can create list instance in SharePoint when you create list this later reference its list template using feature ID the problem is that vsewss change the feature ID all the time what happens is that when you uninstall solution and deploy the wsp if you had list this later will complain that it could not found the list template feature actually this list is referring to the old feature ID the same feature had been deployed with new feature ID.

Another drawback that I think is in the fixing phase is the impossibility of using feature properties such as ActivateOnDefault, scope, etc. Because the feature files is overwritten dynamically every time you deploy.

Hope this helps

Answer 14

I have both VSeWSS and STSDEV installed. I had a hard time figuring out how to use VSeWSS properly, but STSDEV pointed me in the right direction immediately.

As mentioned before, STSDEV is transparent, and a pro for me: the code is available on codeplex, so if something is missing you van add/extend it for your own personal needs. And just looking at the code helps you understand the build process for SharePoint.

Answer 15

I found VSeWSS 1.2 caused a few problems but have found 1.3 to do everything I need it to and pretty much rock solid. This has been for a WCM site with page layouts, web parts and template files. I have not used it for a full site definition install or lists etc

Answer 16

I'm an STSDEV user myself, using a version I have customised for my needs (benefit of open source!). The use of multiple target configurations I couldn't do without anymore - it is an absolute life saver.

I also want to point out, thought, that VSeWSS 1.3 CTP does have "Copy to 12" and "Copy GAC" implemented in a much more accurate way than STSDEV and I presume WSP Builder. The latter tools will simply copy everything under the RootFiles (or whatever) folder, including stuff you don't actually want deployed there such as .cs files or SVN folders. VSeWSS 1.3 always builds a manifest on any compile, and bases its "Copy to 12" off files in the manifest rather than the folder. I'd like to see this in STSDEV at some point.

Answer 17

I've used vsewss, wspbuilder and stsdev to build many web part, site defintion and event handler solutions. I've also done it by hand. The only method with no limitations is to do it by hand. On the other hand, VSeWSS is the basis for SharePoint 2010 support in Visual Studio 2010. If you want to go the most supported route and you are just starting to use one of these tools today, I would recommend you look at VSeWSS first. Have you seen the posts from current 2010 developers who say they haven't touched a manifest or ddf file in months? That is the future. It doesn't hurt to build a solution by hand or with one of the open source tools once for the pratical hands on experience, but after that, why go through the pain?

Answer 18

We use VSeWSS, in the begining when the versions were changing and not all the developers on the team upgraded at the same time. We had a lot of trouble with the stability. This was partly due to the way the solution file is merged by Visual Studio.

At one point we lost most of the functionality from the context menu.

To fix this we ended up creating a new solution file from scratch and adding all the existing projects to it. After that it has been relativily stable.

Answer 19

WSPBuilder all the way, for the same reasons as people posted above! It is an amazingly easy tool to use. I started using VSeWSS and kept pulling out my hair, then I found WSPBuilder and it was love at first site (:-p)!