locked
Upgrading Workflows RRS feed

  • Question

  • I know and understand the issues of upgrading a workflow definition; but how does this apply to the custom activities within them.

    Am I correct in saying that the custom activities are merely classes used by the workflow and are not actually persisted within the workflow instance? As a result, so long as your custom activity allows for upgrades (in the same was as you would for a normal class) by preserving the interface then all will be well and your CustomActivityV2 will support existing persisted workflows.

    TIA
    Alan
    All things are difficult before they are easy
    Monday, April 6, 2009 10:56 AM

Answers

  • I'm not sure but I do know that each custom activity gets a row in the Types table that specifics the DLL and version number and I'd assume that persisted workflow reference these types. Also, I think the workflows do persist the custom activities, as everything in a workflow is an activity and i don't see why they'd get special treatment so your approach may not work as serialization could fail but I personally don't know enough about serialization to know for sure.


    If my response answers your question, please mark it as the "Answer" by clicking that button above my post.
    • Marked as answer by Yi-Lun Luo Friday, April 10, 2009 11:02 AM
    Tuesday, April 7, 2009 7:11 PM
    Moderator
  • The SqlWorkflowPersistenceService uses the BinaryFormatter to serialize the activities for storage in the persistence store. Even assuming you're not versioning the assembly that the activities reside in (or, you are versioning, leaving the version number the same), you will be very limited in what you would be able to change without breaking the deserialization. In order to "preserve the interface" you'd have to leave all methods, properties, and fields (public and, I think private, too) alone. The only thing that would probably be safe to modify would be the code and local variables in the method implementations.
    Wednesday, April 8, 2009 3:59 PM

All replies

  • I'm not sure but I do know that each custom activity gets a row in the Types table that specifics the DLL and version number and I'd assume that persisted workflow reference these types. Also, I think the workflows do persist the custom activities, as everything in a workflow is an activity and i don't see why they'd get special treatment so your approach may not work as serialization could fail but I personally don't know enough about serialization to know for sure.


    If my response answers your question, please mark it as the "Answer" by clicking that button above my post.
    • Marked as answer by Yi-Lun Luo Friday, April 10, 2009 11:02 AM
    Tuesday, April 7, 2009 7:11 PM
    Moderator
  • The SqlWorkflowPersistenceService uses the BinaryFormatter to serialize the activities for storage in the persistence store. Even assuming you're not versioning the assembly that the activities reside in (or, you are versioning, leaving the version number the same), you will be very limited in what you would be able to change without breaking the deserialization. In order to "preserve the interface" you'd have to leave all methods, properties, and fields (public and, I think private, too) alone. The only thing that would probably be safe to modify would be the code and local variables in the method implementations.
    Wednesday, April 8, 2009 3:59 PM