In this follow up post I try to tackle the more advanced stuff which is possible with the new ninject extension for Windows Workflow Foundation. The goal is to show the following topics:
Hooking into the injection chain
Possible side effects
Changing the extensions behavior
Download the extension
In my last post I raised the following questions:
How do you inject dependencies into activities without having to declare the dependencies as input arguments?
How do you build up extensions using DI mechanism?
How do you unit test components which host workflow applications or workflow invokers without actually invoking a real workflow?
In this follow up post I try to answer these questions.
Windows Workflow Foundation 4 offers a comprehensive set of tools to design, create and host your own workflows in your application. Normally when working with WF4 the only way to get your external dependencies into the workflow is by passing the dependencies as arguments to the workflow host such as WorkflowApplication, WorkflowInvoker or WorkflowServiceHost.