Share Point

SharePoint: 10 Things You Wish They Had Told You, Part 1 http://www.devx.com/codemag/Article/39028

In this article, I am going to talk about five things from an architect or management point of view that you will probably end up wishing you had known before you started your SharePoint project. In part two of this article I will follow up with five more things targeted specifically for the SharePoint developer. One fine day, I put my customer hat on and decided to learn about "What is SharePoint?" I browsed around to find Microsoft's description of the product, and found the following: Microsoft Office SharePoint Server 2007 is a new server program that is part of the 2007 Microsoft Office system. Your organization can use Office SharePoint Server 2007 to facilitate collaboration, provide content management features, implement business processes, and supply access to information that is essential to organizational goals and processes. Brilliant. That helped a lot. I am now thoroughly convinced that there is actually a department at Microsoft whose sole focus is to come up with boring product names and mind-numbingly generic product definitions. But collaboration, and being productive, and meeting organizational goals (whatever they may be) is what everyone wants, right? Of course! And thus, SharePoint entered the organization and was installed. It empowered end users. They created lists, and document libraries, even sites and sub-sites willy-nilly. It was a beautiful honeymoon. And like all honeymoons, it was short. Two blinks and you had three crying kids, a mortgage, and a recessionary job market. Users found themselves a bit lost in the UI. They really didn't want to share information, so they broke site permission inheritance, locked out the administrators—and then forgot their password. A wild sprawl of SharePoint sites ensued, and the search indexer kept getting stuck. Users were not happy, and it was all the IT department's (your) fault. Now you'll find out: It didn't have to be that way! You don't have a time machine, but if you did, and for the sake of your next SharePoint project, I will share some tips to keep your life in a SharePoint project sane. Customize the Out-of-the-Box Roles Please carefully observe the following complex mathematical equation:

Number_of_Users X User_Permissions = Your_Headache

It cannot get any simpler than that. Now, it is my view (and only my view), that the out-of-the-box permission levels of Full control, design, contribute, etc., are way too sparse, by which I mean either too liberal or too limiting. You might find it rather shocking, but even the out-of-the-box Approval workflow cannot be properly implemented with the out-of-the-box permissions. Lucky for you, SharePoint 2007 allows fine-grained permission-level control. You can find a detailed description in this related article, but briefly, always study your requirements, and start out with a small

set of users who have the fewest possible permissions. Gradually open the permissions and the number of users, to keep the headache level manageable. Trim the UI To put what you're trying to do in context, I've laid out the following items in order of complexity. •

Light Bulb: A light bulb is rather simple. You flick a switch and 99.999% of the time it turns on.

•

Dog: You pet a dog, and it wags its tail. Sometimes it may bite.

•

SharePoint: More on this shortly.

•

Men: It's not that flicking the light switch should turn the bulb on, but first we must question, is light truly what we need? Let's call a meeting.

•

Women: Well, I'm a man, so I cannot understand them myself, much less explain them to you.

SharePoint, as you can see, is more complex than a dog, but less complex than a human. Isn't that what most computer software is becoming anyway? You flick a switch, and the bulb will turn on—most of the time. Customers still want to treat computer systems like light bulbs. They expect things to work, always, and they don't have the patience to learn software's idiosyncrasies. That's why the iPod is so successful. The answer is, make your computer system simple. Don't make users think in terms of "Lists." Let them think in terms of the business problem they are trying to fix. Trim the UI to suit your project. So, how exactly do you trim the UI? Here are some ways: •

Customize the default master page. Don't show SharePoint stuff like "View all lists" to users who only have read-only permission. It makes no sense to them.

•

Ensure that your architecture does not require users to ever view the application master page.

•

Offer in-place editing of displayed text.

Always Use Features Let me dispel some myths. SharePoint is a platform, not a solution. Most of the work begins after you have installed SharePoint. Out-of-the-box solutions rarely do exactly what you want. But the beauty of every Microsoft platform lies in its extensibility. And yes, while it is tempting to point and click and create a working product for end users, such behavior will only get you into trouble in the long run, because: 1. Simplistic procedures ignore the software development lifecycle. In other words, what you did on the production box never went through QA. 2. Simplistic procedures create crazy expectations in users' minds. While you could set up a blog easily, you cannot set up a chat room easily. Users may not understand why, and the out-of-thebox blog might not be exactly what the user wanted. Therefore, you must treat SharePoint sites just like you should any other software project: understand the business requirements, create functional requirements, design, write a feature or features, package them up as a solution, apply version control, and deploy them to production after QA with great care and love. Site Definitions Are So 1980s Seriously, if you think delivering a SharePoint project is the equivalent of writing a site definition, it's time to get a haircut and step into the 90s.

The problem with site definitions is that they are monolithic. The original intent was to create a cookie cutter with which you could create multiple cookies, all of which looked identical. In reality, immediately after you delivered the first five sites, the users each wanted a slight change. And shortly after that, users wanted divergent paths. Sites 10-15 will have only some characteristics similar to sites 15-20, and even fewer characteristics similar to sites 1-10. If you had bunched together your functionality as features instead of site definitions, your life would have been so much easier. Features work better than site definitions because: 1. They can be scoped to web, site, IIS website, and farm. 2. They can be turned off or on, independent of other features. A site definition is either the whole enchilada or death by starvation. 3. Features come with receivers. You can run code before and after they activate or deactivate. Site definitions do have site provision providers, but they are not as flexible. 4. Features can be stapled to existing site definitions. Thus, out-of-the-box site definitions can be customized, without actually changing the physical files. 5. Features are well-suited to a version 2.0 scenario. Let's say you wrote a site definition, which now requires version 2.0. What do you do next? Write a new site definition, or a feature? A new site definition will not work. You will have to write a feature. I like to start with the basic site definition and trim everything I can. I'll then add some things I know I will need. For instance, I am a huge fan of URL rewriting, in-place editing, and better RSS capabilities, and I use these features as my base development site definition. I wish there were a standard development site definition (there isn't). But one day, in my spare (!?) time, I will create one and put it on CodePlex. If you are interested in helping, please contact me. Define Roles within Your Team A typical software shop has some major roles. For example, both infrastructure people and application developers have major roles involved in any project. SharePoint introduces some interesting challenges. Infrastructure people can do much of the solution delivery, and application developers can do a lot of configuration, but the overlap of roles can create confusion. Before you embark on any SharePoint project, define clear roles. I suggest these basic tenets: •

Wean yourself away from point-and-click configurations in the production environment, except: during the initial install, while working inside the central admin, with the SSP (Shared Service Provider), and when provisioning new Web sites or site collections. All these exceptions fall into the hands of the infrastructure staff.

•

Always deliver new functionality using solutions. Application developers should author these solutions on separate machines over which they have full control.

•

New functionality is driven, and architected by, application developers. Its design and architecture is vetted by infrastructure.

If you are currently in the middle of a SharePoint 2007 project, you probably understand why these tips are so important for architects or management. The next article in this series discusses five tips targeted toward developers tips that can also save a lot of time.

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.

H 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.

3. Reverse-Engineering SharePoint "Invention is the art of hiding the source of your inspiration." When you see something interesting happen on a SharePoint web page, you may wonder how you could replicate that feature in your own sites. You could start poring through the documentation, ask your friends how to do it, or delegate it to your staff. But perhaps the best option is to cheat by peeking into SharePoint to find out how they did it! I'd encourage you to cheat, guilt free, by using the following two methods:

1. Peek into the SharePoint 12 folder, and look in the Templates\Features folder and see how certain features are written.

2. When authoring a custom feature targeting list definitions, content types, or views, if you're

struggling with the specific CAML syntax, create the list definition manually, and point your browser to the URL http://yoursiteurl/_vti_bin/owssvr.dll?Cmd=ExportList&List={YourListGUI D}.

This second 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. 4. Fix that Annoying Web Part There was a time when a bunch of Coke-bottle-glasses-wearing scientists pored over punch cards for hours before they dared put them into a computer. But computers are so much cheaper now that the standard development method has turned into: 1. Write code. 2. Throw at computer. 3. See if it works. 4. If it doesn't work, debug and fix on the fly. Go to #2. 5. If it works, go home and play Tetris.

The problem is that a developer may sometimes throw in a Web Part that totally brings down the hosting page to such an extent that the page won't even run; you can't even see the "Edit" menu to remove the offending Web Part. Luckily, there is a back door that lets you remove such Web Parts to fix the page. Simply go to the URL http:///_layouts/spcontnt.aspx?&url=. That page presents you with a menu to clean out these Web Parts from both shared and personal views. 5. Avoiding IISRESET A fair criticism of SharePoint is how much it likes to make you run IISReset whenever 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 because your production web farm probably consists of more than one web server—you can update one while the others are running. But in development, IISReset can get annoying. Every time you hit IISReset, you lose five seconds of your life. 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. To do that, 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 is extremely slow. That occurs because ASP.NET recompiles the web application. I like to include Spence Harbar's application recycle utility in my SharePoint virtual machines. 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. SharePoint for developers is a huge topic. There is plenty for a developer to learn—and do—in a SharePoint project. This article discussed only a few of the relatively important tips you might need. Happy developing!