VSeWSS: At Least It Knows CAML

Scot Hillier just posted an excellent answer to the question “Is VSeWSS 1.2 Ready for Prime Time?” In the comments, Microsoft’s Chris Johnson follows up with the assertion that the extensions cover 99% of what a developer might need. I would put that number a bit lower, but more important is the first impression given by the tools.

As the logical first tool for new developers, the extensions will undoubtedly play a formative role in how that developer thinks about SharePoint development. Scot highlights one such problem in the provided project templates: two of the four (plus empty) are Site Definitions. To a new developer, this implies that Site Definitions are probably really important, when in fact you (probably) don’t need them.

Another fundamental shortcoming of the extensions is the black box method of solution creation. Managing DDF files and manifest.xml can certainly be tedious, but there comes a time when every developer needs to tweak something in the solution definition. Scot’s example is the forced inclusion of an assembly; a quick glance at the Solution Schema reveals several others (SafeControls and CAS in particular). This is a huge blind spot in a new developer’s understanding of how SharePoint really works.

Update: A bit more research reveals that you can indeed add SafeControls (example by Chris Johnson) and CAS to the manifest.xml in WSP View. Better examples might be RootFiles or Resources, which don’t seem to have anywhere to go in a VSeWSS project.

Less prevalent but equally disarming is that the project just ignores files that it doesn’t understand. I had originally planned to use the branding lab of the VSeWSS-based SharePoint Hands on Labs (download) as an example for my latest post on using features to update SPTHEMES.XML. The process went something like this:

  1. Open VSeWSS project
  2. Add New Item > Module
  3. In new feature: Add Existing Item > Browse to SPTHEMES.XML
  4. Switch to WSP view and update the feature.xml with the new <ElementFile />
  5. Deploy
  6. Error: Cannot find this file specified in the manifest file:
  7. Sigh…

Missing ElementFile
The only way I could get my file included in the solution was to add it to the module:
<File Path="SPTHEMES.XML" Url="ThanksVSeWSS" />
Which has an undesired side effect:
Thanks VSeWSS

Ultimately the problem comes down to the tool not allowing someone that knows better to take control. A bike with permanent training wheels is eventually outgrown.

As A CAML Tool

Specific limitations aside, Chris did hit on a very important use of the extensions: heavy lifting of the XML files. I have found no better way to generate the extensive XML required for List Definitions Templates, Content Types and such. (For more help authoring XML, check out AC’s tools.) New developers in particular should use the extensions to build a few content types, lists, instances, etc. to see how everything fits together. But what if we want to use these XML files with another solutionizing method (WSPBuilder, STSDEV, PowerShell, batch files)? We could certainly retrieve them from the 12 hive after deployment, but it turns out there’s an easier way.

When a VSeWSS project is deployed, it stores the full directory structure of the WSP in $(TargetDir)\solution. All we need to do is pull the appropriate folders into a new project built with the tool of your choice: LAYOUTS, IMAGES, etc. into TEMPLATE; feature folders into TEMPLATE\FEATURES; and so forth. Note that the solution directory only stays populated if the deployment succeeds, and you will need to retract the VSeWSS solution (or change the feature IDs) before you can install the features as part of the new solution. Just like SPD, we use the tool for its strengths and then pull what we need out into a project of our own design. I imagine a similar approach could probably be used with WebParts, though I haven’t done anything with them in VSeWSS.

Ultimately I have to agree with Scot that, despite tremendous potential for future releases, for now VSeWSS just doesn’t quite have the flexibility needed for sophisticated solution development. That said, it’s very solid in its strengths and definitely has its uses in the context of your chosen development approach.

Posted in SharePoint, Tools. Tags: . 3 Comments »

3 Responses to “VSeWSS: At Least It Knows CAML”

  1. Bob Says:

    Have you found a way to include files (.gifs, ect) in the solution? I am trying to use in the manifest, but get the same error.

    but cant get around the error.
    “Error: Cannot find this file specified in the manifest file”

  2. Keith Dahlby Says:

    You’re getting a “Cannot find this file…” error because VSeWSS doesn’t know to include the file in the WSP itself. Since you’re modifying manifest.xml, I assume you’re trying to include additional <TemplateFile /> elements, in which case you need to use the “Template” item type. Once you have a “Templates” item in your project, just “Add Existing” to put your file in the appropriate place in the project hierarchy (under IMAGES\MyFeature for a .gif, perhaps). When you deploy the project, VSeWSS will rebuild manifest.xml with the new <TemplateFile /> and know to include it in the WSP.

    Chris Johnson describes this process with pictures here.

  3. Scott Says:

    I’ve used VSeWSS v1.1 (VS2005) and v1.2 (VS2008), as well as seeing the screenshots/previews of v1.3…

    Overall, my impressions are:
    1) VSeWSS does *NOT* follow traditional development methodologies; it instead follows SHAREPOINT solution (WSP) methodologies. Do not expect an ‘images’ folder to just magically include itself, figure out how SP likes to store images, how VSeWSS maps its components (“items”), and go from there. (following my example, images are stored in 12\TEMPLATE\Images, add the TemplateItem folder, add Images subfolder, (create project subfolder) and drop images.
    *note: this seems to be the BIGGEST stumbling block of all dev’s i’ve seen… they want to treat VS/WSP’s like an ASP.Net app that they’ll figure out entirely on their own, when VSeWSS wants to leave the customization to the dev and take care of the SP/WSP “stuff”.

    2) support for solution components… some components are just down right difficult to develop (you mentioned the RootFiles stuff, I specifically think of WebServices which need to go into 12\ISAPI, whereas VSeWSS only allows 12\TEMPLATE and below)… though this is being improved in v1.3 (which includes templates for 12-folder level custom components. Adding project assemblies (including a biz layer assembly from a dependent project in the VS solution)… again, 1.3 is going to be changing a *lot* of these limitations.

    3) the biggest frustration in the development environment… VSeWSS requires SP, requires Windows Server, which often means Virtual Machines… not a bad idea, as I like a blank slate for each WSP/project i work on… but virtualization includes costs (VPC only supports single thread, VPC/VS support only x86 and no SMP, etc etc).

    what VSeWSS does EXTREMELY well:
    build/deploy process – VSeWSS automatically performs the build/package/retract/uninstall/install/deploy/reset for SP… this is how packages will be used in production, and mirroring the process is *WELL* worth while… WSPBuilder and others like to assist (command to package)… but often aren’t as well integrated (post-build scripts, etc)… and xcopy’ing to the 12-hive and GAC (even though it’s being added in VSeWSS 1.3) is a somewhat half-assed approach… maybe for some agile stuff, but especially test and final build should use the full process


Comments are closed.

%d bloggers like this: