In post post I’m going to cover PowerShell Workflows and Visual Studio. When I saw PowerShell Workflow and how it was using Windows Workflow behind the scenes I wondered how it fitted in with designing workflows in the Visual Studio designer. With C# creating large workflows is easier in the Visual Studio designer instead of coding them, I wanted to see if it was the same for PowerShell and how it worked in the designer.
When you create a workflow script in PowerShell it generates a XAML workflow that is executed by .NET. The commands you use in your script are transformed into PowerShell activities in the XAML workflow. If your code doesn’t have a corresponding PowerShell activity it is wrapped in an InlineScript activity. This is transparent to the user but it can have ramifications. The code in an InlineScript activity is executed in a separate PowerShell instance that is loaded for each activity and stays active for the whole activity, this can be bad for performance when running workflows at scale. Activities in a workflow have lots of plumbing around them and the code in the InlineScript activity will not have that plumbing available. For instance you can’t checkpoint inside your InlineScript activity so you won’t be able to recover to a specific point inside the InlineScript. To illustrate the transformation, look at the script sample below:
Here is the equivalent workflow that is generated with Write-Output resulting in a WriteOutput activity and Start-BitsTransfer resulting in an InlineScript activity.
I’m not aware of a command in PowerShell that will inform you if your code has a corresponding workflow activity but you can do a visual inspection by exporting your workflow to XAML, opening it in Visual Studio and looking for InlineScript activities or searching the XAML text for InlineScript. Using the same script as above, I wrote the XAML to a file which you can open in Visual Studio.
(get-command Invoke-MyFirstWorkFlow).XamlDefinition |out-file c:\temp\MyFirstWorkFlow.xaml
You can view the activities available by adding them to the toolbox in the workflow designer. As far as I could see most of them are in these assemblies.
- Microsoft.PowerShell.Activities
- Microsoft.PowerShell.Core.Activities
- Microsoft.PowerShell.Diagnostics.Activities
- Microsoft.PowerShell.Management.Activities
- Microsoft.PowerShell.Security.Activities
- Microsoft.PowerShell.Utility.Activities
- Microsoft.WSMan.Management.Activities
I uploaded the list of PowerShell workflow activities I found in the above assemblies along with their corresponding PowerShell commands over here.
In theory you can design your workflow in Visual Studio, import the XAML file in PowerShell and execute it like the example below.
I assume this is not the intended use-case since it didn’t work that well for large workflows, especially if you are not using the PipeLine activity and that limits you to activities that is pipeline enabled. I think part of the problem is all the extra plumbing activities that PowerShell injects to handle expressions and variable values etc which you have to do now as well.
PowerShell can also execute workflows from XAML files by importing the file as a module.
Import-Module "C:\Temp\PowerWorkFlow.xaml" PowerWorkFlow #name of the workflow
If you are going to distribute and re-use the workflow you should package it like a proper PowerShell module instead of passing the XAML file around.
While going through all of this I started to wonder why you would use PowerShell workflows in the first place since they have a bit of a learning curve and many restrictions. Hopefully I’ll be doing a post on that soon.
