In my previous article, I talked about 10 things you wish you knew before you started your SharePoint project.
The first five things were focused more towards the architecture and management of the project. In this article, I will follow up with five things targeted specifically for the SharePoint developer.
Have you heard the latest buzz around town? SharePoint is a platform. I think this news even caught 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 opening Visual Studio and cutting and paring the product to suit your specific needs. Also, since SharePoint 2007 is built on ASP.NET 2.0, it is significantly customizable.
While SharePoint for the ASP.NET 2.0 developer is a huge topic, in this article I am going to talk about five specific things that made my SharePoint development life easier.
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 needed 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, I’d like you to check out the following tools:
- CKS: Available at www.codeplex.com/cks, the Community kit for SharePoint is a combination of a number of SharePoint projects solving some key scenarios. Of course, nothing stops you from “borrowing” ideas.
- WSPBuilder: Available at www.codeplex.com/wspbuilder eliminates the need to craft and maintain 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.
- STSDEV: Available at www.codeplex.com/stsdev, STSDev is another such utility that lets you create Visual Studio projects to support the feature set you are trying to add to SharePoint.
- You can find many other useful tools at http://www.codeplex.com/Project/ProjectDirectory.aspx?TagName=Sharepoint.
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 the 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”. Depending on your logging settings it will 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 be 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”.
The following simple steps to the web.config will turn your SharePoint install into a debugger friendly environment:
- Change the configuration\SharePoint\SafeMode\@CallStack attribute to “true”.
- Change the configuration\system.web\compilation\@debug attribute to “true”.
- 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.
Reverse Engineering SharePoint
“Invention is the art of hiding the source of your inspiration.”
Okay, you see something interesting happen on a SharePoint Web page, and you wonder how you could replicate that in a feature. You could then start poring through documentation, start asking friends, or if you’re lucky delegate it to your staff. But perhaps the best option is to cheat. Be able to peek into SharePoint and find out how they did it!
I’d encourage you to cheat, guilt free, by using the following two methods:
- Peek into the SharePoint 12 folder, and look in the Templates\Features folder and see how certain features are written.
- When authoring a custom feature targeting list definitions, content types, or views, if you’re struggling with the specific CAML syntax, hand create the list definition and point your browser to the following URL: http://yoursiteurl/_vti_bin/owssvr.dll?Cmd=ExportList&List={YourListGUID}
Now this approach isn’t perfect. Sometimes the CAML it produces may not validate with the schema, and the CAML structure it produces may not be production ready. But it serves as a perfectly good starting point to copy and paste pieces out of the generated XML, so you don’t have to start at zero.
Fixing that Annoying WebPart
There was a time when a bunch of Coke-bottle-glasses scientists pored over punch cards for hours before they dared put them into a computer. Since computers have gotten so much cheaper now, the standard development method has turned into:
- Write code.
- Throw at computer.
- See if it works.
- If it doesn’t work febug/fix on the fly. Go to #2.
- If it works, go home and play Tetris.
The problem is: Sometimes a developer may throw a Web Part that totally brings down a Web Part page. Brings it down to such an extent that the page won’t even run and you can’t even see the “Edit” menu to remove that offending Web Part.
Luckily, in order to fix the Web page, there is a back door to removing such really smelly Web Parts. Simply go to the following URL: http://<mosssite>/_layouts/spcontnt.aspx?&url=<insertRelativeUrlHere>
This page will present you with a menu to clean out these Web Parts from both shared and personal views.
That Sucky IISRESET
A fair criticism of SharePoint is how much it likes to IISReset every time you deploy new functionality. Now, in the real world it shouldn’t matter much because you can always schedule code deployments at the end of the day, and your production Web farm should hopefully consist of more than one Web server.
But in development, IISReset can get annoying. Every time you hit IISReset, you lose five seconds of your life. Much like cigarettes, by the time you are 70, this will have added up to a few days lost.
A much quicker way is to recycle only the application pool instead of issuing an IISReset. In order to recycle just the application pool, you can use the following command:
cscript c:\windows\system32\iisapp.vbs
/a "[App_Pool_Name]" /r
A related issue is that every time you recycle either the application pool or issue an IISReset, the next request to SharePoint seems extremely slow. This is because ASP.NET recompiles the Web application. I like to include Spence Harbar’s application recycle utility in my SharePoint virtual machines, which you can download from http://www.harbar.net/articles/APM.aspx. I can use this tool to warm up my SharePoint URLs and precompile them, so when a user accesses them, they appear responsive and quick.
Summary
SharePoint for developers is a huge topic. There is plenty for a developer to learn, and do, in a SharePoint project. This article talks about the first few, and I share some of the relatively more important tips you might need.
Happy developing!
