VSeWSS vs WSPBuilder vs STSDEV for WSS 3.0 / SharePoint 2007 development

sharepoint.stackexchange https://sharepoint.stackexchange.com/questions/37

Question

What are your personal experiences with using these tools?

I tried VSeWSS when it first came out and was frustrated by it. Each new version has been the same for me but for different reasons.

WSPBuilder greatly appealed to me because I could clearly see where my files were being deployed on the server. Its use of reflection to create CAS files and packaging of WSPs has been great, as well as the starter templates it provides.

Recently someone pointed me in the direction of STSDEV. I know this tool has been around for a long time but I know very little about it.

From your own experience, which would you recommend and how did you come to this decision?

Was it helpful?

Solution

I've built hundreds of solutions and web parts using every tool out there (including rolling my own from scratch). WSP is the best tool IMHO for what I do.

It's low friction to get started (get the Visual Studio add-in!) and lets you quickly get a web part/feature up and running instantly. Then you can work your solution and do a one-click deploy in development then package it up easily (using the command line tool and something like NAnt/MSBuild) for delivery to a staging/production environment. Unlike STSDEV (which requires custom build targets) or VSeWSS (which requires you to structure your code a certain way) it let's me work the way I want to and is adaptable and flexible.

VSeWSS is nice in the fact you can use it reverse engineer something like a .stp file created site into source files (for example the fab-40 application templates) which is useful but that's the only reason I would us it.

STSDEV is nice but it feels awkward and tends to completely rebuild everything each compile (meaning the ddf generation). It also forces me into a certain structure and last time I checked it there were issues with multiple web parts in a single feature, etc. It could get better but WSPBuilder gives me what I need today.

OTHER TIPS

WSPBuilder is the choice for me, gives you so much for free when developing and a great integration with Visual Studio. There are a lot of hidden gems in WSPBuilder, that you easily forget, such as great automatic CAS generation. Do read Tobias Zimmergrens post on how to get started with it: http://www.zimmergren.net/archive/2009/04/08/wspbuilder-walkthrough-of-the-visual-studio-add-in.aspx

/WW

One thing I would add is that if you a beginning, try not to jump straight in using these tools. Try to learn how to create a WSP by hand first. That will give you a far better grasp on how these tools are meant to work and how they help. It will also give you an understanding of what to look for if there is an issue with a WSP created by one of the tools.

I use WSPBuilder (with the VS 2008 add-in) in combination with a custom project template I can develop a working web part and deploy this into my dev environment in about 2 minutes!

For single solution packages with one-one relationship to assemblies (which is most small scale projects) this is fine.

Just recently had some issues with a larger project with mutliple assembly references, but I am sure it is me not setting it all up right rather than a problem with the tool per-se.

VSeWSS was clunky and awkward last time I used it and its put me off trying again. SP 2010 looks like it could imporve on this so I will probably revisit this again.

STSDev is something I have not tried much because WSPBuilder has fulfilled my needs thus far.

'Copy to GAC' and 'Copy to 12 Hive' features are developer heaven!

I'm definately a fan of wspbuilder, I like the structure too but the 1.3 vsewss templates look a heap better than the earlier versions. I think if I was starting dev now I'd consider them first and may not need wspbuilder, will be insteresting to see if that is the case with 2010.

WSPBuilder is my current tool of choice, I think VSeWSS is useful for people starting out to use in a SandPit setup, but once you get into real projects it has limitations and just hides too much away from you.

I also still use good old fashioned post build events for speed.

WSPBuilder can stub out a solution, feature and web part in under 30 seconds, whereas before it could take up to an hour. Huge save on development time, keeps you focused on the functionality you're trying to produce AND there are some cool deployment features. The other thing is using WSPBuilder in conjunction with SharePoint Solution Installer allows you to generate a WSP that be can be installed via a wizardy Setup.exe file. Never touch STSADM. AND! You can also configure it to automatically activate features upon installation by just adding a single like to the config file. I'm loving it and recommend it to all my SharePoint peeps.

STSDEV is my option. I've build over 30 SharePoint custom solutions involving event handlers, wf, custom web parts, custom application pages and I'm very pleased with STSDEV. One reason is that everything is transparent, you can see the STSADM commands in output windiw and you can run them later on production server. And yes ..stay away from VSeWSS is the worst.

I am a big fan of VSeWSS 1.3 March CTP, but it is not perfect. This version of VSeWSS seems to follow the SharePoint devlopment rules better than previous versions.

The biggest issues that I have noticed with VSeWSS is ...

  1. When developing a web part and attaching and .ascx control to the web part for display, I noticed that when you try to go into Design or Split view you will see errors. You can get around this by copying your ascx file to the root of the project, open the ascx file, and move it back to your correct location in the project. I think this is more of a Visual Studio 2008 issue.

  2. When working with features DO NOT mess with the feature IDs. It will mess things up badly... How do you change a feature id in a VSeWSS project... Not sure, I think its black magic.

  3. If you are creating a Site Definition in VSeWSS 1.3 CTP you need to ensure that you exclude the pkg folder from your project when deploying otherwise you could see and error message. So before I can check my code int I need to include the PKG folder back into my project and then exclude it when I work on the project agian. What a pain!

If there is anything I learned about VSeWSS is DON'T mess with the pkg folder and instead use the WSP view. Other than these minor issues, VSeWSS 1.3 CTP has been great! Remember its just a Comminity Technology Preview(CTP) and we should be seeing the Release To Web(RTW) version very soon.

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?]

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.

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.

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

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.

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

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.

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?

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.

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)!

Licensed under: CC-BY-SA with attribution
Not affiliated with sharepoint.stackexchange
scroll top