Versioning WF in 4.0

Question

Does anyone know of any resources on versioning WF 4.0 similar to this artcle for 3.5: http://msdn.microsoft.com/en-us/magazine/dd727506.aspx

---

If my response answers your question, please mark it as the "Answer" by clicking that button above my post.

My blog: http://www.RyanVice.net/

Answer 1

Hi, Ryan

Many methods mentioned in this article are also works in WF4, such as .net versioning.

In WF4, we can no long change a workflow in the mid-fight. Since the most vast usage of WF4 is xamlx workflow host in IIS7/Appfabric. my personal sulution is including the version info in the workflow name. for example, if you have a running workflow named NewHireWorkflow.xamlx. when you changed the workflow and want both old and new workflows coexisted. you can rename the new workflow: NewHireWorkflow_1.1.xamlx.

Hope this helps
Regards

---

This posting is provided "AS IS" with no warranties, and confers no rights. Microsoft Online Community Support. My Blog:http://xhinker.com "Microsoft Windows Workflow Foundation 4.0 Cookbook"

Answer 2

Hi Andrew,

Wait, dynamic update doesn't work in 4.0?

 

---

If my response answers your question, please mark it as the "Answer" by clicking that button above my post.

My blog: http://www.RyanVice.net/

Answer 3

Ryan, indeed Dynamic Update was cut along the way. Hopefully, we'll see it come back in the next version as part of a larger versioning story. 

I don't have a fully updated story on versioning for you, but here are some thoughts.

1) Since everything is (or can be) loose XML, you can more easily select particular versions of a workflow definition by using filenames (or DB columns if you store you workflows in the database).  This is useful for creating new workflows.

2) for existing workflows that you want to finish using their original definition, you can take advantage of the PersistenceIOParticipant model to store the definition in the database, and load it back up with the instance resumes. The SDK samples have an example of this in the WF\Basic\Execution\ControllingWorkflowApplications directory.  It uses WorkflowApplication and uses the stored definition when resuming workflows.

3) Activiites are usually compiled and so the .NET versioning story CAN play a role here because the system is going to try and create those based on strong name.  HOWEVER, becuase the activities are not serialized into the persistence store, you don't have NEARLY as many issues when loading workflow state from the database; especially since only in scope state is stored in the database. 

4) #3 also applies to workflows (which are just activities after all) where the state stored is about bookmarks, variables, arguments, etc. and not the serialized state of the activity.  So you can often supply a modified defintion when loading from the persistence store and not run into problems.  The biggets problem with this is that I haven't yet seen any documentation on what changes are/are not breaking changes. 

5) workflow services are based off the XAML(X) file and use whatever activity is providing the defintion for the service.  Therefore, it's much harder to continue to use the initial workflow definition without changing endpoints.  You can modify the workflow service and test that the changes made still enable full retrival from the persistence store. 

6) Using extensions (the replacement for workflow services) still provides some abstraction for the activities as well so that might help out in some situations.  Definitely useful for unit testing.

Hope this is helpful information.  I plan to dig into this when I get some time. I'll blog it when I do. 

Matt

---

Free Guest Pass – Experience .NET training the way it should be.

Answer 4

Thanks Matt and Andrew! You guys always are the best sources for information on WF. I taught a class yesterday at Houston's Tech Fest and I strongly recomended that anyone who was serious about workflow get Andrew's Workflow Foundation 4.0 Cookbook and subscribe to PluralSight to get access to Matt's excellent on demand courses. I used the new 4.0 PluralSight courses to help me prepare for the class and they were so good!

---

If my response answers your question, please mark it as the "Answer" by clicking that button above my post.

My blog: http://www.RyanVice.net/

Answer 5

Matt,

Do you have any resources or more information on how persistence works now? I knew that only the current scope was persisted but I assumed that the activites were still serialized. If they aren't serialized then how is their state maintained?

---

If my response answers your question, please mark it as the "Answer" by clicking that button above my post.

My blog: http://www.RyanVice.net/

Answer 6

Andrew:

Say, there is a Service called HireService in NewHireWorkflow.xamlx and if you include the new workflow NewHireWorkflow_1.1.xamlx in the same library, how is the host going to publish two services with the same name?

Also, even though I get the concept of Versioning the Workflow Service, I am still not sure how to handle the changes from the client side.  For example, Say I built a web client that allows users to access an operation AddUser [which takes a User Object as parameter: class User {name, address, age}] from HireService and after a while due to some business need/change, I have to add another attribute [ssn] to the User class so that it looks like class User {name, address, age, ssn}.

Now, those workflows which are already running still need to access the operation AddUser from the previous Workflow.  Say my webform is addUser.aspx which invokes AddUser Operation from previous Workflow.. and new webform becomes addUser_1.1.aspx so that it has extra field for the new service version.

My Question is how do I detect right verison of workflow service from the client side for a particular instance so that I can present the user addUser.aspx and not addUser_1.1.aspx?  Do I keep track of the workflow version on the client side as well?

Thanks,