Fear and Loathing

Okay, here we are kids. It's 2006 and life is grand ain't it? So what would the first post of the year be for me, why it's the sessions I'm holding at this years SharePoint tracks as part of the DevConnections conference April 2-5, 2006 at the Hyatt Regency Grand Cypress, Orlando, Florida (whew, that's a mouthful).

As I tripped over Bob Mixon's blog I see that the final PDF brochure thingamajig is avaiable (why am I always the last to know?). You can check out all the good stuff you could see (for a few thousand dollars) right here, but since this blog is all about me, here's my happy-go-lucky SharePoint sessions for you to look forward to:

RABBIT TEST: BUILDING UNIT TESTING WEB PARTS USING TDD AND SHAREPOINT
In this session, we’ll talk about some of the real problems developers face when trying to test Web Parts in the real world with real applications. We’ll explore some techniques for making Web Part development a little more testable (using NUnit), build a Web Part using a Test Driven Development (TDD) approach, and have an open discussion about when and where we might want and might not want to implement unit tests in real world applications.

HARD CORE LOGO: A DEEP DIVE INTO SHAREPOINT BRANDING
Customizing a portal or Web site is always the first order of business when someone implements SharePoint. Companies always want their sites to look and feel right to their customers. Employees want to feel at home with their portal so it looks like the rest of the organization. Custom applications need to look like
they’re part of the big picture. You’ll start from the humble beginnings of customization from simple logo changes up to complete overhauls of the look and feel of SharePoint. This includes both portal and theme customization and some tricks and tips you can use to get big results for very little effort. By the end of the session, you’ll be able to take that drab and dreary SharePoint look and make it your own.

MINORITY REPORT: THE ART AND SCIENCE OF BUILDING REPORTS FROM SHAREPOINT DATA
What good is data if you can’t report against it? The reporting capabilities of SharePoint are basic, but in this session we use some custom and third-party solutions to dive into the contents of your lists and document libraries in order to get good value out of what you put into them. We’ll build some reports on the fly using existing tools then rip open the covers in the object model to turn your SharePoint list into a well-tuned data reporting machine.

Not only do you get to listen to me blather on about SharePoint for many hours, but you also get:

• A free one-year subscription to MSDN magazine
• A one-year subscription to SSWUG.ORG (with something to do with SQL, like that's important or something)
• A six-month subscription to SQL Server magazine (only six months?)
• Three fun-filled happy meals, err, lunches
• Live organ transplants (as we seem to have missed out at PDC with these)
• Three continental breakfasts
• One low-fat carb-free reception (well, I can't guarantee the low-fat or carb-free part)
• One Theme Party (come as your favorite 6-0 Hive!)
• Conference T-Shirt and Bag (to wear to the Theme Party of course)
• Software (non-specific but I'll be it's not porn)
• Proceedings Book and Resource CD

Should be a blast so hope to see you there! Remember to book early at DevConnections.com for some cool deals and tell them Bil sent you (well, don't actually as it may hinder my ability to be there and I've already got my spiderman jammies all packed for the trip).

Hopefully everyone is happy and back at work and now eating leftover turkey and stuffing for the next few weeks. I know I am. The entire crew was over for the holidays yet the fridge is still full of goodies. Hmm, wonder if that veggie tray can keep for a year in the fridge?

Anyways, with the release of VS2005 and the recent service packs for SharePoint there is still lots of confusion over building applications and web parts with VS2005 and what works and what doesn't. As there is confusion, it must mean the information out there isn't clear enough for people to understand. In my infinite wisdom I figure why not add another log on the fire so hopefully this post will either make things as clear as mud, or really leave you scratching your head.

Getting Started
First off, you must have the .NET framework (version 2.xx) installed on your server (and your dev envrionment if you have one) for all this to work. Before you go off and do that (if it hasn't already been done yet) make sure you have the absolute latest service packs for both Windows SharePoint Services and SharePoint Portal Server. Okay? Great. Now you're ready to rock.

Building .NET Applications
Obviously, with ASP.NET 2.0 installed and running on the server you can build a regular web app using 2.0 no problem. You can use any part of the new 2.0 framework like new controls, the membership provider, the sitemap, etc. but you cannot use System.UI.WebControls.WebParts (see below). Things to check on your setup:

• Make sure you exclude the path to the application (the name of the virtual server) in your SharePoint configuration, otherwise it'll think it's part of the SharePoint system and try to do evil things to your app.
• Make sure IIS is using 2.0 of the framework for your app. You can check this in the IIS manager. Right click and they'll be a new tab for setting the ASP.NET version on that virtual directory.

Building Web Parts
Here's where things get tricky. First off, forget about using the System.UI.WebControls.WebParts namespace or inheriting from that WebPart class. Those type of WebParts (very much the same as SharePoints) have their own manager and tie into various parts of the framework and the support just isn't there yet (as far as SharePoint goes). When V3 rolls around you'll be able to build WebParts using this framework and the ASP.NET 2.0 WebPart will be almost identical to the SharePoint WebPart class.

Next is building SharePoint Web Parts (referencing the 1.1 assembly) with VS2005. It can be done but takes a little work. As there is no 2.0 template yet, you'll either need to have VS2003 hanging around to build you a skeleton Web Part or keep a blank one handy. In order for the web part to work with WSS you'll need to go into the site in IIS and ensure that the website is using ASP.NET 2.0. You will also need to use the stsadm forceupdate option to force SharePoint to perform the update (after you flip the website over to use 2.0), the command is:

cd /d %commonprogramfiles%\Microsoft Shared\Web Server Extensions\60\Bin
stsadm -o upgrade -forceupgrade

You should do an IISRESET just to make sure everything is applied. Now development of Web Parts is the same as ASP.NET 1.1 except you can use .NET 2.0 features (like Generics, Anonymous Delegates, ObjectDataSource, etc.). The most important thing to note here is that you can ONLY do this with Windows SharePoint Services. SharePoint Portal Server has to run on ASP.NET 1.1. as 2.0 isn't supported. SQL 2005 and other "2.0-ish" features are supported, but the runtime isn't which means you can't compile a WebPart and have it work in Portal Server. A good reference as to what works and what doesn't based on service pack installed can be found here. Bottom line is that if you want to build ASP.NET 2.0 Web Parts using VS2005, you can only do it on a Windows SharePoint Services (WSS) site install (not SPS with WSS).

Now if you want to build a 1.1 WebPart on SharePoint Portal Server that *talks* to an ASP.NET 2.0 application, that can be done because in IIS you can set the web site to use ASP.NET 2.0 and have the Portal Server WebPart communicate (through web services, remoting, etc.) to the 2.0 web part. It takes a little work, but if you keep your Web Parts to only presentation (which is what they're supposed to do) then there's nothing to say you can't have a 2.0 Business Layer talking to a 1.1 Web Part on Portal Server (using all the features of SPS like single sign-on, enterprise search, etc.). SharePoint Portal Server doesn't care that .NET 2.0 is installed on it, it just can't be targetted to use it.

As an alternative option, you can use the Son of SmartPart (I think Jans hates that name). This little doofer uses the 2.0 framework and will just suck up little ASP.NET user controls and render them out via a Web Part in SharePoint. So yes, you can build something that looks and smells like a Web Part using .NET 2.0 and running on SharePoint right now but:

• You must have the .NET framework 2.0 deployed to your server
• You must be running the latest Service Packs for all products installed (SPS if present and WSS)
• You can only deploy 2.0 assemblies to a WSS only setup, not WSS running under SPS (since you can't split the IIS virtual server into two and it has to be targetted to 2.0)

That's a lot of musts but it can be done. I'm sure there *might* be other ways you can do it (and I hope I didn't miss anything), but for other ways you'll probably have to do some magic incantations and sacrifice a small marsupial to get it working.

Hope that helps.

No fancy "Twas the night before SharePoint" post. Just well wishes for you and yours during this festivus. Enjoy and be safe!

Then try Bob Mixon's replacement Quick Launch! This is tres cool so thumbs up from me (and I didn't even know he was working on this). Not only does it look exactly like the default Quick Launch (meaning you could go and replace it on everyone's site without them knowing, sneaky huh?) but check out some other cool features he's added:

• The ability to turn any set of lists on or off. So if you chose to not display Surveys, simply turn it off.
• The ability to display separation lines below the grouping headers.
• The ability to display an Actions section with access to manage site settings, users, content, and alerts.
• The ability to display icons next to items
• And, the best of all features, the ability to dynamically add any items to the quick launch bar (with your own groupings) through a standard SharePoint list.

You totally have to check it out here. Go. Go now. What are you waiting for?

If there's one thing I really love, it's SharePoint (well, sometimes). And Plugins. Those cute little furry dll files that you drop into a directory and make programs do cool things. So why not combine the two?

I'm putting together a SharePoint Admin Host tool that's driven entirely by plugins. How so you ask? Well, it's pretty simple. Using my SPS Wrapper classes and connecting to a SharePoint server via web services I have a host that will let you do pretty much whatever you want against the SharePoint information. A Plugin manager inside the host will look for dlls and load them at runtime. They also expose the wrapper classes to your plugin, so you can do things against SharePoint without doing any heavy lifting.

The Host does two things for the plugins. First it connects, via web services, to the server and builds a tree of all areas, sites, lists, etc. (dynamically as you expand nodes on a treeview of your portal/wss site). Second, it communicates the selected node(s) to your plugin as a fully typed class that you can interact with. All without SharePoint on your client desktop.

What can you do with this? You can build plugins for it silly. So lets say the user fires it up and connects to his portal then selects a few areas. You can write a plugin that creates a subarea (based on available templates from the portal) under each of the areas selected. Or the user selects all the sites in the tree. You can write a plugin that applies a theme against all of them in one fell swoop. Want to create client side reports from SharePoint data? No problem. It's all there, waiting to be unlocked. You just have to write the guts.

So what do I need? I need developers to write plugins. Email me and I'll hook you up with a development kit. It includes one PluginInterface.dll that you'll reference in your assembly and derive your plugin classes from the public interface available. An API document on writing plugins with all the methods you need (there are only a few) and classes that you can use to access SharePoint information from. Sample plugins with source (C#). A lifetime subscription to Rice-a-Roni, the San Francisco treat, and the hosting program that will run all this junk (plus my undying support and other good stuff).

Just send me off an email with your info, what plugins you're thinking about writing, your social security number, the number of Senators in Congress today, and anything else you can think of. I'll get you started and we'll look at forming a small community for this where people can download new plugins as they become availalble (much like the add-on community that exists for something like say FireFox).

Well, important if you're Japanese and have a problem with the translated text for the Later than filter criteria field and for the Earlier than filter criteria field being switched. Here's your hotfix.

Don't know how many Japanese readers I have (I wasn't able to get into the Google Analytics beta fast enough) and how many of those run SharePoint Portal Server but for those that are there and care, this ones for you!

Isn't technology wonderful?

A bit of a sidetrack as I was planning to blog with pics on the mod for putting your image above the menu bar (I still don't agree with Heather that her solution works, nyah) so I will get to that, but later.

I did want to mention a couple of things about posting questions about SharePoint (in newsgroups, forums, wherever). First, please read your posts before you click the big send button. I don't know how many times we sit there trying to decipher a request when there's a typo in it. Really. It's quite simple. Proof read your post (being a blog, question on a forum, or an email) and make sure it sounds like it makes sense. Okay, maybe I'm guilty of this on my blog but like I said, there have been more times than I can remember where I've been reading the newsgroups and questions are being thrown about that make absolutely no sense. Relax, take your time, and read your own scribblings before you inject them onto the world. Gonzo journalism is great, but you need to master it before you can fire off posts without editing. Seriously. It will expedite the process of getting an answer if the guy on the other end of the line knows what you're asking.

Next is the big one. Recently there's been a pretty meaty selection of posts and emails with people asking if SharePoint can do this or SharePoint can do that. Some don't even ask if the tool can do it but rather go to the big, dark place of "I have to implement x using SharePoint or I'll get <fired | castrated | exiled | etc.>". Guys (and girls), hate to break it to you but SharePoint is not a shape-shifting, set your phasers on stun, beast from 20,000 fathoms tool that is all things to all people all of the time.

Yeah, drink that in for a minute.

It has custom lists, document libraries, it's web based, can version documents, has security, audiences, single-sign on, blah, blah, blah, blah, blah, blah. However it does not: make you dinner; vacuum your living room; teach your 7 year old tennis; play ball with your dog; impregnate your cat; dust your buffet and hutch; talk to your Xbox 360 (well, maybe); or generally do stuff it wasn't designed for. Yeah, it's a great tool and one that is very powerful but you, as an implementer of SharePoint need to know the design boundaries of it and stop ripping it apart to do your bidding. You wouldn't use your light sabre for grating cheese would you? So stop making your SharePoint deployment do crazy things. Yes, it *can* do it but *should* it? Probably not.

Give you a few examples. We all know that lookup lists are kind of clunky. The can only use lookup values from the current site, can't use calculated fields to lookup from, and they can't filter values in the lookup. These are design limitations. Live with it. Can you achieve these things? Sure. Write a wrapper to simulate the ListFormWebPart (i.e. rewrite it) and you make it do whatever you want. Write some funky JavaScript (like SharePoint doesn't have enough of this already) to filter your lists, call a web service, and otherwise rewrite the page on the fly. Create your own ISAPI filter to do what SharePoint doesn't do.

C'mon people. Give your head a shake. If the answer to your problem isn't already in front of you then maybe it's not something that you should try to do. There's being creative, then there's just bastardizing the tool to make it do something. That's not creative, it's just plain dumb. Does Microsoft Word do a great job of editing information that might be better suited for a spreadsheet? Then use Excel. Use the right tool for the right job.

Custom Web Parts can give you ultimate flexibility, but like anything they're expensive to develop. Yeah, even that 10 line Web Part to hide something on the page is 10 lines you have to feed, maintain, and grow. Update when the next version comes along. Add to version control. Document so when you get hit by a bus the next guy knows what it's used for. And so on. Development is fun but expensive so ask yourself if you can't solve a problem with an OOTB solution maybe adjust your problem (or it's parameters) so that it fits the technology you have to work from.

Web Parts will give you what you need, but at a price and too much of a good thing might be too much on a Web Part Page. 20 Web Parts on a single page, while they're all doing "important stuff" might take 30 seconds or so to render per person (as it's fetching data from all over the planet). Having this as your home page in your organization might just bring down your SharePoint server. Is this a design flaw or a launch problem? It's responsible development that you need to look at holistically and not just from the "I need x to solve my problem" type of approach.

In any case, you can achieve great things with a great tool but like any tool, you need to use it responsibly and with malice aforethought about what you're doing. Before you go off to build the uber-web part that will deliver everything under the sun, ask yourself if you really need it or can you leverage what you already have.

Software development is full of compromises and sometimes you just have to say no. No to the communications person screaming that they want their image on the right instead of the left. No to the HR person yelling that they want the form to dynamically change based on the users gender and way that they're sitting in the chair. No to the finance guy that wants to use SharePoint as his SAP replacement and do the entire corporations payroll with custom lists and 8,000 lines of JavaScript for the business calculations.

Trust me, you'll be better off in the long run.

Thank the maker that Stubbs the Zombie, the *only* game in which you become the Zombie and get to do uber-cool things like eat brains and possess people (something I sometimes need to do at work) is now officially supported on the Xbox 360 (previously it wasn't listed on the backward compatible list). Very cool.

Of course now there's the issue of me finding a 360 in Calgary, which is pretty much impossible. The Best Buy/Future Shop guys say "well, show up in the morning and maybe we'll have one". Uhh, no. Why can't I just walk in and get one? I mean, it's not like there's no demand (yeah, yeah, grumble, grumble, supply, supply). Bah, humbug!