Login | Register   
LinkedIn
Google+
Twitter
RSS Feed
Download our iPhone app
TODAY'S HEADLINES  |   ARTICLE ARCHIVE  |   FORUMS  |   TIP BANK
Browse DevX
Sign up for e-mail newsletters from DevX


advertisement
 

SharePoint Applied: 10 Things You Wish They Had Told You—Part 2

Part 1 of this two-part article covered five architecture- and management-focused topics you wish they had told you about SharePoint. This article follows up with five more topics targeted specifically toward SharePoint developers.


advertisement
ave you heard the latest buzz around town? SharePoint is a platform! I think this news caught even Microsoft by surprise. I say that because SharePoint is still grouped under the "server" category and seems to get more IT Pro treatment than developer treatment. The fact is, though, that there is a burgeoning SharePoint developer community, and Microsoft is making significant strides and investments in improving the developer story around SharePoint. As a developer, you are probably someone who is not afraid of using Visual Studio to cut and prune SharePoint to suit your specific needs. You can do that because SharePoint 2007 is built on ASP.NET 2.0, and it's significantly customizable.

While SharePoint for ASP.NET 2.0 developers is a huge topic, this article presents five specific topics that can make your SharePoint development life easier. 1. Use Community Tools
To a great extent, the .NET developer community has embraced non-Microsoft, and even open-source tools, to improve their development experience. However, the key difference is that even without using community developer tools, the plain vanilla .NET developer can get by with the tools that Microsoft ships. I love Visual Studio, but for SharePoint specifically, I wish there was an easy way to craft solutions and feature projects. VSeWSS (Visual Studio extensions for Windows SharePoint Services) is available, but it seems a bit behind what the community already has to offer. I am quite certain that developer tool support from Microsoft will improve, but what if you need to deliver a project today?

In the SharePoint world, it is much more acceptable, and frankly deemed an implicit standard to use certain community tools in your development. Specifically, you should to check out the following tools:

  1. CKS: This Community Kit for SharePoint combines several SharePoint projects that solve some key scenarios. Of course, nothing stops you from "borrowing" ideas.
  2. WSPBuilder: This project eliminates the need to craft and maintain the cryptic .ddf files you would usually use to create .wsp solution packages. WSPBuilder iterates through your project structure and creates a .wsp file for you.
  3. STSDEV: This utility lets you create Visual Studio projects to support the feature set you are trying to add to SharePoint.
You can explore some other useful tools as well.


2. Enable Debugging
Debugging is as integral to writing code as tequila is to Mexico. A SharePoint developer's machine must have SharePoint installed locally, along with Visual Studio and other necessary development tools. And installing SharePoint locally means grabbing it off your MSDN subscription or similar location and installing it in a typical configuration—one that was never meant for debugging. So, when you run into an error in your custom code, SharePoint will simply say "Unexpected Error Occurred." At that point, depending on your logging settings, it will either log the error to a flat file, not create a log, or create a shorter log. That is actually a good thing, because you don't want to expose the gory details of your error (which could possibly contain security-sensitive details) to a remote client over a browser.

But when it comes to debugging, logging to a flat file is not such a good thing, because you want to hit breakpoints and see real error messages instead of seeing "Something bad happened." But it's a relatively easy problem to fix. The following simple alterations to the web.config file will turn your SharePoint install into a debugger-friendly environment:

  1. Change the configuration\SharePoint\SafeMode\@CallStack attribute to "true."
  2. Change the configuration\system.web\compilation\@debug attribute to "true"
  3. Change the configuration\system.web\customErrors\@mode attribute to "Off."
That's it. Now when you attach your debugger to the SharePoint w3wp.exe process, it will stop at your breakpoints. Also, instead of seeing "Unexpected Error Occurred," you will now see a full stack trace and error messages.
Editor's Note: This article was first published in the September/October 2008 issue of CoDe Magazine, and is reprinted here by permission.



Comment and Contribute

 

 

 

 

 


(Maximum characters: 1200). You have 1200 characters left.

 

 

Sitemap