One Very Long Day with WSS
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.
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.
I am currently the Editor-in-Chief for MSDN Magazine. I joined Microsoft in 2006 as a product planner with the certification team at Microsoft Learning. Prior to that, I spent my career as a developer and later as an architect. My main technology passions include pretty much anything on language theory, agile development, and service-oriented architecture.
