Freigeben über


Upgrade Paths for Custom MSBuild Tasks

I’m regularly asked what’s the best way to upgrade an MSBuild-based build process to a Workflow Foundation-based build process and one of the most important parts of this is how to leverage the investment and dependence you have on any custom MBBuild tasks you’ve written. This post outlines four different ways you can make your custom MSBuild tasks callable from a Workflow Foundation workflow.

Use MSBuild Activity to call MSBuild wrapper around MSBuild task

  1. Create a very simple MSBuild project with a single target that calls the MSBuild task.
  2. Arguments are passed as properties to the MSBuild project which passes them to the MSBuild task. Complex properties (arrays, objects, etc.) need to be converted to strings to be passed as a property to the MSBuild project.

Pros:

  • No coding required.
  • Simple.
  • Leverages existing MSBuild knowledge.
  • No modifications to existing MSBuild task. Don't even need access to it's source.
  • Not much Workflow Foundation knowledge required.
  • MSBuild task can still be used from MSBuild.

Cons:

  • I'm not sure how you'd deal with output properties in this solution.
  • Limited debugging experience.
  • Limited testability.
  • Don't have full access to the Workflow Runtime from MSBuild project or MSBuild task.
  • Not a simple drag drop experience to call the task from a workflow.

Wrap MSBuild task in a custom Workflow Activity

  1. Create a custom workflow activity with the same properties as the custom MSBuild task.
  2. Custom workflow activity instantiates a copy of the MSBuild task and proxies it's properties through to the custom MSBuild task.
  3. When the workflow activity is executed then it invokes Execute on the MSBuild task.

Pros:

  • Can deal with output properties.
  • Easier to deal with complex properties.
  • Improved debugging experience.
  • Improved testability.
  • Can access the Workflow Runtime in the wrapper.
  • No modifications to existing MSBuild task. Don't even need access to it's source.
  • Can still call the MSBuild task from MSBuild.
  • Simple drag drop experience to use the workflow activity from a workflow.

Cons:

  • Coding required.
  • Some infrastructure classes would be need to trick the custom MSBuild task into thinking it's running in an MSBuild environment.
  • Workflow Foundation knowledge required.

Rewrite MSBuild task as a Workflow Activity

  1. Rewrite the MSBuild task as a Workflow Activity.
  2. [Optional] Write an MSBuild wrapper for the Workflow Activity.

Pros:

  • Can deal with output properties.
  • Easier to deal with complex properties.
  • Improved debugging experience.
  • Improved testability.
  • Can take full advantage of Workflow runtime.
  • Simple drag drop experience to use the workflow activity from a workflow.
  • Minimal ongoing maintenance.

Cons:

  • Access to MSBuild task source is required.
  • Coding required.
  • Workflow Foundation knowledge required.
  • No longer callable from MSBuild (unless you do Step 2).

Extract custom task logic into a POCO class and provide an MSBuild Task and Workflow Activity adapters

  1. Extract the logic into a basic class that uses properties for input/output parameters and has an Execute method that returns a Boolean indicating success.
  2. Create a custom MSBuild task that calls the extracted class.
  3. Create a custom Workflow Activity that calls the extracted class.

Pros:

  • Can deal with output properties.
  • Easier to deal with complex properties.
  • Improved debugging experience.
  • Improved testability.
  • Fully usable from MSBuild and Workflow Foundation.
  • MSBuild wrapper can take full advantage of MSBuild runtime.
  • Workflow Activity wrapper can take full advantage of Workflow runtime.
  • Simple drag drop experience to use the workflow activity from a workflow.
  • Enables you to expose the same logic in additional forms later (PowerShell cmdlets, WCF service, etc.).

Cons:

  • Access to MSBuild task source is required.
  • Coding required.
  • MSBuild knowledge required.
  • Workflow Foundation knowledge required.
  • Increased maintenance.