Versioning long running workflows part 4

Part 1 Part 2 Part 3 Part 4 In the previous blog posts we made sure we could have multiple versions of the same workflow running side by side. This ability is one of the more powerful concepts of WF and a real must have for long running business applications. A quick recap. Always version your assemblies by giving them a strong name. Make sure the runtime can find each version of the assembly by pointing the CLR to the right version using the configuration\runtimeassemblyBinding\dependentAssembly\assemblyIdentity\codeBase in your App.Config (or Web.Config in the case of a web application). And make sure … Continue reading Versioning long running workflows part 4

A bit more about using TransactionScopeActivity within a ReceiveActivity

Part 1part 2Part 3Part 4 You may recall my previous posts about using the TransactionScopeActivity within a ReceiveActivity and all the nasty issues we ran into. Just in case you want to read them again: one, two and three. As it turn out this is an intentionally not supported scenario at the moment. If we read the docs for the ReceiveActivity we can find the following note: To ensure that persistence performs properly and does not persist transient messages, make sure that child activities of the ReceiveActivity do not persist by themselves. This can occur if the child activities go … Continue reading A bit more about using TransactionScopeActivity within a ReceiveActivity

Versioning long running workfows part 3

Part 1 Part 2 Part 3 Part 4 In the first article of this series I demonstrated how to get multiple versions of a workflow running side by side in the same  workflow runtime. The most important thing was that you need to keep every version of the assembly around and use the assemblyBinding element in the app.config to let the runtime know where each version was on disk. Once done life was good [:)] In the second part I demonstrated how a HandleExternalEventActivity was version dependent and you needed to use the version specific service to send a message … Continue reading Versioning long running workfows part 3

Versioning long running workflows part 2

Part 1 Part 2 Part 3 Part 4 In my previous post I demonstrated how to keep multiple versions of an assembly around and how to use the assemblyBinding element in the app.config to let the runtime load multiple versions of a worklfow. In the end we had both workflows, the first in assembly 1.0.0.0 and the second in assembly 2.0.0.0, running and life seemed to be good [:)] So is there more to write on the subject? Yes unfortunately there are still some potential problems that need to be addressed [:(].   The pitfalls of External Data Exchange Lets … Continue reading Versioning long running workflows part 2

Versioning long running workfows part 1

Part 1 Part 2 Part 3 Part 4   One of the cool features of Windows Workflow Foundation is that it allows long  running processes. And not just long running as in a few minutes but really long running as in a few years [:)]. This is possible true the use of the SqlWorkflowPersistenceService, or in fact any derived class from WorkflowPersistenceService, which is going to save the state of a workflow to disk when it is not actually busy. So that is pretty cool but it is kind of unlikely that your programs are not going to change over … Continue reading Versioning long running workfows part 1

Changing a Declarative Rule Condition at runtime

One powerful feature of a workflow is that a workflow can be changed at runtime. Like other powerful features this is something that should be done with care but it can be a real life saver at times. One of the things that you can change are Declarative Rule Conditions. However as these rules are really CodeDom objects it can be a bit tricky to find the right property to change. However once you know a little tick life is much easier. The trick is in the .rules file created when you add a Declarative Rule Condition to the workflow … Continue reading Changing a Declarative Rule Condition at runtime