Another SharePoint Developer/Debugging Tips List

If you can only follow a single SharePoint developer blog, it should probably be Andrew Connell (even if hitting Enter in his Search box still doesn’t work in Firefox). If for some reason you haven’t already, make sure you’ve read his excellent SharePoint developer tips and tricks and SharePoint Debugging and Logging Tips and Tricks. Here are a few additional tips from comments there and elsewhere:

Debugger.Launch()

AC suggests System.Diagnostics.Trace.Assert(false) to force the debugger; System.Diagnostics.Debugger.Launch() is a more explicit alternative (featured on Corey’s .NET Tip of the Day).

Debugging GAC’d Assemblies

AC says “you’ll need to put the debugging symbols in the same location as the assembly.” While a few of the comments hint that for them it “just works” without that step, that’s probably due to a setting in their environment: Just My Code debugging is likely off. Vincent Rothwell’s Debugging Tips for SharePoint mentions this setting in passing and it has since been highlighted here and here as well.

Attaching to w3wp

Debugging doesn’t work if you aren’t attached to the right IIS worker process. One option is to use the Debugger Feature from the CodePlex Features project, which adds a new menu item to the Site Actions menu that attaches the debugger. If you would rather not install a feature, Doug Perkes suggests adding a VS External Tool to list the PIDs:

  • Title: Get IIS PIDs
  • Command: cscript.exe
  • Arguments: %systemroot%\system32\iisapp.vbs
  • Check “Use Output Window”

More External Tools

Speaking of which, Scot Hillier has put together a CodePlex project to support his development process. The installation includes several useful External Tools and more than a dozen developer-focused STSADM extensions. My favorites are enumpools and recyclepool; much more SharePointy than iisapp.vbs /r /a. Or for a GUI try Spence Harbar‘s Application Pool Recycle Utility for SharePoint Developers. For even more STSADM extensions (and some great SP object model code in general), check out Gary Lapointe’s blog.

Opening WSPs

Some developers prefer to make a copy of their WSPs with a .CAB extension as part of their development process, but if you don’t mind modifying the registry Waldek Mastykarz has a nice post on browsing .wsp files using Windows Explorer. Or if WinRAR is your tool of choice, a .reg with the following will do the trick:

Windows Registry Editor Version 5.00

[HKEY_CLASSES_ROOT\.wsp]
@="WinRAR"

Easy Access to 12 and VirtualDirectories

Waldek also posted about getting quickly to the VirtualDirectories folder in Explorer View. Many developers use a 12 Hive Toolbar; I use the same technique for VirtualDirectories. As for opening in Explorer View, why not make that the default Folder action? Here’s another .reg that does just that:

Windows Registry Editor Version 5.00

[HKEY_CLASSES_ROOT\Folder\shell]
@="explore"

Managing CAML

If I don’t stop myself now I’ll end up with a comprehensive list of every cool SharePoint thing I’ve seen in the last year. So I’ll leave you with Katrien’s list instead.

Update 7/12/2008: Added U2U CAML Query Builder.

Advertisements

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:
    NewBrandTheme\NewBrandTheme\SPTHEMES.XML
  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 »