There and Back Again : SharePoint

SharePoint Goodness

hdierking — Wed, 25 Jun 2008 23:57:06 GMT

SharePoint is one of those technologies for me that is large enough in scope and ambition that I am simultaneously in awe of it and confused by it. To elaborate on the confusing aspect, SharePoint feels like it has multiple masters - more specifically, it's hard to know who should be paying attention to it. Is it a system admin type of product? Is it a developer platform? Is it a collaboration portal for use by regular users. The answer, which speaks both to the power and the confusion, is "absolutely yes".

I personally buy into the vision of SharePoint as a web application platform. I don't think we're there yet, but it makes a lot of sense to me that we'll get there. That said, it's still really confusing as a developer to know where to get started with SharePoint (although Ted has done a fantastic job at trying to help dense folks like myself). I was recently forwarded an email, however, with some great resources for getting started as a developer. First, there's the Web site http://www.microsoft.com/click/SharePointDeveloper/ - there are a lot of great jumping off points here. There's also a great set of getting started Webcasts. For more information on that, check out Paul's post.

Check it out.

OBA - Are We There Yet?

hdierking — Sun, 26 Aug 2007 08:40:04 GMT

I am a beliver in the power of Office as the pre-eminant smart client for the majority of LOB applicaitons. However, I also think that we're still a little ways off from realizing my belief - not because of some entrenched NIH complex held to by consultants (though there is some of that (NOTE: because I was a consultant for at least half of my career, I take the liberty of making such broad generalizations in good fun <g>)). - but because in general, both the tooling and the guidance for building business apps based on Office as a platform has been somewhere between sketchy and non-existant.

Office 2007 brought us closer with the adoption of the OpenXML document formats - and with the forthcoming VSTO enhancements, like click once support for customizations, we take another step. Also, today I stumbled upon this piece of guidance for developers - I'm not sure that it's necessarily guidance, but it certainly at least lays out the different options (and it just looks cool).

So while we're not yet past having to deal with COM and all of its associated headaches, we can at least have a pretty WPF applet to play with.

SharePoint Exams are Live

hdierking — Tue, 27 Mar 2007 03:18:02 GMT

In case you had not seen the announcement anywhere else, I wanted to let you know that the 2 SharePoint exams are now available. You can find the prep guides here.

We still need to change the "Exam News" section on the prep guides to reflect that the exams have been released – so don't let that stop you from registering.

Good Luck!

One Very Long Day with WSS

hdierking — Mon, 26 Mar 2007 07:43:41 GMT

Actually, my ordeal began yesterday, but since I didn't really sleep much last night as a result, the whole thing just feels like one very long day. At any rate, here's the context. I'm trying to automate a business process that involves the creation of a document by several individuals followed by an approval process by a couple more individuals. I thought, "hey – since WSS 3.0 allows for the tying of lists to WF workflows, it's a great platform to automate this process." And while this may be true in theory, the practical realities of implanting such a solution are far from straightforward. I should preface by telling you that while I have a background in software development, I am approaching WSS development as a newbie.

Firstly, let's chat about what you need to even begin to develop workflows for WSS. One of the first things that I discovered was the fact that you must have WSS installed on your development machine. Well, I'm certainly not going to install it on my core workstation – so I fired up a VPC and installed the following.

Windows 2003 Server
IIS (Add the Application Server Role)
Microsoft .NET 3.0 Framework
Windows SharePoint Services 3.0
Visual Studio 2005
Visual Studio 2005 Extensions for Windows Workflow Foundation
WSS 3.0 SDK

The one thing that you may notice was missing here is SQL Server. Since this is just my development environment, I'm fine with just using the SQL Express database – plus, by this point, I'm sick and tired of installing stuff.

Now, on to the more interesting stuff – building a workflow in WF and using WSS as the host. My good friend Rob Bogue wrote an article recently describing how to do just this. The article was fantastic and at the end of the day, I was able to get my workflow to execute correctly. However, the journey was not without some problems (largely because of WSS tooling support, not Rob's article) and had I not been able to catch Rob on IM, I may not have had the success that I did. If you are not new to WSS development, some of these things may seem pretty obvious – however, if you are, hopefully they might save you a bit of time and frustration.

The first problem I ran into happened when I opened the workflow designer. Now, I don't know if this was intentionally left out of the installation package or if my installation just did something strange, but the WSS activities never got registered with Visual Studio. Therefore, I had to create the toolbar tab myself and add the activities to it. Not a huge deal – just something to be aware of. The next problem I ran into happened when I was creating the feature XML. Just like the activities, the WSS related snippets apparently did not get registered with Visual Studio. In fact, not only were the snippets not available, but the XSD schema did not get dropped into the proper place for general VS consumption either. I therefore, had to find and add each manually. You can add the snippets by bringing up the snippets manager dialog (Tools -> Code Snippets Manager), clicking the "Add…" button, and selecting the "C:\Program Files\Microsoft Visual Studio 8\Xml\1033\Snippets\Windows SharePoint Services Workflow\" folder. The SharePoint XSD schema that you can point to in all of your XML documents can be found at "C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\XML\wss.xsd". Now, I think that if I had also installed the Windows SharePoint Services 3.0 Tools: Visual Studio 2005 Extensions package, I might not have need to register all of these things manually – perhaps one of you can clear that up for me.

The next thing was just my stupidity, but if you've never run into this before, just know that when trying to extract the public key token from an assembly by using sn.exe, know that there is a significant difference between 'sn –T …' and 'sn –t …'. I'm not even going to tell you how long it took me to realize why I kept getting an error.

Finally, the most significant problem I encountered was when deploying. My project built successfully every time, and I didn't notice any installation errors when I installed into WSS (though I finally saw one when Rob pointed me to the WSS log files), but I could never get my document content type to show up when trying to add it to my document library. As it turned out, the problem was that I had accidentally (through the magic of cut and paste) derived both my custom document content type and my custom task content type from the same base content type (0x01080). While the error was in fact my own, I am completely amazed at how convoluted the method of deriving WSS content types is. If you are not familiar with the process, I don't want to spoil it for you, so go read Rob's article or check out the MSDN guidance. Sufficed to say, the process is very manual, very moniker centric, and very much by convention (translation – very error prone).

After discovering this error, deactivating my WSS feature, uninstalling my feature, then reinstalling and activating it, I was able to create a new document and have my workflow run. However, I have to say that the whole process left me with somewhat of a bad taste in my mouth. Granted, the benefits of truly automating a people-centric workflow probably outweigh the initial pains of getting the workflow setup, but good grief – does it have to be this complicated? Personally, I think that SharePoint is an absolutely fantastic platform for building the next generation of LOB and BI solutions. However, if the tooling doesn't get dramatically simplified (DSL anyone?), I'm afraid that it will never amount to much more than a standard-looking website that people use as a document repository.