Book Review: Inside Microsoft Windows SharePoint Services 3.0


I just recently began my journey down the road of learning about WSS and MOSS. My primary focus of course is for the workflow portion of the product, but what I have found while building that base of knowledge, is that you do need to know quite a bit about SharePoint just to be able to understand what you can do with custom workflows.


I picked up this book written by Ted Pattison and Daniel Larson and I’ve been very impressed with the content, the level of detail and code samples. I can see that this is a book I am going to reference again and again.  I was actually working with a client who had WSS questions the week I purchased this book and the answers were right there in front of me. Talk about good timing!


This book is definitely for the developer but it does have topics and admin might be interested in like SharePoint architecture, deployment and application security.  And of course the chapter on workflow was most excellent…the text was very clear at explaining several of the properties and fields that are critical pieces of custom workflows.


I’m not sure what those folks who have lots of experience with WSS think of the book, but for me, it was a good purchase.

Versioning Techniques for Workflows

As of right now, there are no documents (whitepapers) available that pertain specifically to workflow versioning other than what you will find on MSDN at


However, out on the forum, there have been several posts related to versioning and to give you an executive summary of what you need to do, there are basically two ways (without doing lots of coding) to handle versioning:


  1. Use workflows that execute based on XAML activitation.  This is where you just read in a .xoml file via an XMLTextReader through the CreateWorkflow method.  As I stated in class, there is no concept of versioning in a .xoml file and there is no concept of security reading the file in this way either, except for the fact that whoever puts the .xoml file on the machine where the host reads it from must have permissions to do so.

  2. Use .Net versioning techniques where you modify the version in the assembly.cs file prior to deploying it. This should allow in process workflows to continue/finish execution and new workflows to startup with the new workflow version.


Here is a link to assembly versioning steps in .Net:


So, that was the executive summary, but even within these two types of versioning tactics, there are some other things to consider:


  1. Are you trying to modify the workflow object structure (ie. Add new dependency properties or methods) or are you trying to add/remove activities?  If you only need to add/remove activities in certain workflow instances, you can still use the WorkflowChanges class to modify these at runtime.  If you are add/removing/changing properties etc of a workflow then you cannot expect a workflow that is currently persisted to be able to be reloaded into a new object structure.

  2. Are you going to be providing workflows or workflow apps to your customers or internal groups and then later wanting to enhance these workflows, without changing the one they have? If you need to do this, it might make more sense to come up with some sort of rules based workflow where you can modify the rules, storing the rules in a database such as we saw with the External Ruleset Demo tool. You can of course change the workflow and rules using the WorkflowChanges class but this only changes the workflow for that one running instance of the workflow, meaning that you would take a performance hit each time you ran the workflow because it would have to be modifying the running workflow instead of executing a compiled version.

  3. If you are going to be using XAML activation, are you going to be linking it to an activity class library? Without using some activity library, just using XAML activation is going to severely limit what you can do with your .xoml file. Since most business logic needs to take place in code, this will most likely mean the code will need to be in a custom activity, which will need to be linked inside of the .xoml file.  So, essentially when you need to update the activity assembly you are once again looking at having to use .Net assembly versioning techniques.



So, how does an persisted, unloaded workflow know which version of the assembly to use when it is reloaded?  When the workflow gets serialized to the database serialized (binary), the assembly and type information gets serialized as well.  This is normal .NET serialization (BinaryFormatter), not anything workflow-specific.  Upon deserialization,  .NET will automatically load the correct assembly based on version (assuming the correct version of the assembly exists in the GAC or config and can be resolved).


The workflow runtime actually knows nothing about workflow versions or any of that.  The instant we serialize a workflow, it’s no longer WF – it’s .NET from then on up to the point after the WF is deserialized again.

In the Beginning…..

Hello All!

I thought pretty hard about how to title this blog and considering that I wanted it to cover topics in Workflow, BizTalk, MOSS WF and anything inter-related, I decided to name it ‘Topics in Integration’. If you have any other thoughts on what to title it, let me know.

I have been quite involved in the Workflow Foundation since its beta and have worked with BizTalk since its early beta. Hopefully, on this blog we’ll be covering some topics that relate to either or both of these together since quite often, when I am discussing one with a customer, the other comes up.