Home > SharePoint Development > Further thoughts on VSeWSS…

Further thoughts on VSeWSS…

Having maligned the previous versions of VSeWSS, I feel it’s only fair to provide more feedback on the latest version… I’ve been using the March CTP version of VSeWSS 1.3 for a while now and it is a vast improvement on the previous versions.

However I still have issues with the solution, manifest and feature XML files being hidden under the pkg folder and VSeWSS automagically updating them on every build. Care needs to be taken in editing these XML files to avoid losing changes or ending up with multiple features, and supporting folders, being created with _1 (or _2 or _3 if you’re really unlucky) appended to the end.

Fortunately there is some guidance on the supported modifications to these files in the latest release notes.

However, in summary, I think VSeWSS 1.3 is very useful SharePoint development tool and I’m looking forward to the full release.

…the alternatives…

One of the advantages offered by VSeWSS is the tight integration with Visual Studio however with the advent of the WSPBuilder Extensions for Visual Studio the game has changed.

Using the WSPBuilder Extensions add-in, SharePoint projects can be created in Visual Studio just as easily as with VSeWSS. WSPBuilder offers a slightly different set of pre-configured SharePoint development projects; these are well described by Tobias Zimmergren on his blog.

WSPBuilder gives the developer access to the feature and element XML files and doesn’t seek to obfuscate them; which is good. The solution and manifest files are generated automatically by WSPBuilder and only visible by extracting the contents of the WSP package. This could prove problematic if any manual edits are required.

It appears that the WSPBuilder extensions still uses the command-line version of the tool to produce the WSP file and therefore can’t use files added to the Visual Studio project as a link because they don’t exist in the physical file structure of the project.

The ability to add linked files is very useful when developing an ASP.NET application to be hosted within SharePoint as the actual .aspx files can be added to the SharePoint solution without xcopying them from the ASP.NET web application’s solution. It is also the method used by the patterns and practices group in their SharePoint Guidance for wrapping an ASP.NET user control in a web part.

Finally, it’s somewhat annoying that WSPBuilder targets all web applications within the farm by default and I’ve not been able to change this behaviour yet.

…and the future

And, as a last word, Visual Studio 2010 should offer built-in SharePoint development projects. Once I’ve had a play with the CTP hopefully I’ll be in a position to offer an opinion on how these compare.

  1. No comments yet.
  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: