0
votes

I have a custom module with some embedded Workflow & Native ps1 cmdlets.

When I import this module, only a subset of the cmdlets are showing up as extracted Activities under the Module.

The module is completing the import successfully, and shows as Available.

Is there anywhere to look to find the specific output and any possible member-specific import errors?

The cmdlets which are failing to load are dependent upon some new types added as part of an assembly. The cmdlets which are loading are also dependent on types from that assembly.

Adding to the confusion, when I import this module locally in ISE, everything works fine and all the cmdlets are available/executable.

Further: I've seen this with Native PowerShell cmdlets, but it also appears as though (single) PowerShell Workflow activity inside a .ps1 is not supported.

In addition, I've seen that locally, depending on whether or not a load my module using the .psd1 or the .psm1, I get different behavior & results WRT dependent assembly loading.

In particular, when trying to troubleshoot the inconsistencies locally, I've gotten a number of "can't find type" or "found more than one overload for ctor with 1 arg" (despite the type in question not having a ctor with 1 arg) errors with types referenced via [OutputType([typename])], etc, when OTHER cmdlets that DO rely on types from the SAME assembly are found just fine..

[EDIT]
local verbose output from my testing .psm1

VERBOSE: Importing function 'sync-test'.
VERBOSE: Importing command as workflow 'Sync-VsoGitRmRunbook'.

In AA, sync-test (just a plain runbook that writes string output) is showing up fine, while Sync-VsoGitRmRunbook does not.

If I convert sync-test to a workflow, it also stops importing, leading me to believe that there is a limitation with modules exporting Workflow activities that are bundled as .ps1 files (as opposed to being C# classes packaged in the module)

[EDIT]
I've created a module that reproduces the problem. https://github.com/JoeBrockhaus/AzureAutomationVsoGitSync

1
I just added a comment to your other post, but can you please share the module? Automation recently released changes to the UX where you should see an error if the module failed to extract activities correctly and should be able to see the underlying error. If you do not see this error, it means that Automation thinks that everything did extract successfully. Seeing the module contents with the cmdlets that failed to extract would help us pinpoint the issue.Elizabeth Cooper
Is there a release update blog post on those UX changes to better surface module loading errors/info? I'd specifically like to see the resulting (verbose) output from the .psm1 (where Export-ModuleMember is called)JoeBrockhaus
There isn't a post about error messages specifically. We did post a service announcement on module import improvements azure.microsoft.com/en-us/updates/automation-module-gallery. If you scroll to the second to last screenshot, we show what activities look like as they are still extracting. If there is a failure, the status column in the modules list will reflect this. On the module blade you will see a failure notification at the top which you can click to see the error that was thrown. This doesn't capture the full verbose output from the import though.Elizabeth Cooper
@ElizabethCooper Gotcha, I just wasn't sure if I was missing something somewhere else, tbh. So, in these cases, I see the 'importing' status (after 'uploading') on the blade. The (subset of) runbooks will eventually appear, and no errors are displayed (the import status will be successful/completed in the notification bar/flyout).JoeBrockhaus
@ElizabethCooper I added a link to my repo that will build the module. Are PowerShell Workflow .ps1 activities exported as module members not supported? This seems to be the issue - the Workflow activities will not import, while Native scripts will.JoeBrockhaus

1 Answers

0
votes

Only PowerShell cmdlets / DSC resources can be imported into Azure Automation through PowerShell modules. If you convert your Workflow activities to cmdlets, import should succeed.

You probably want these Workflow activities to be cmdlets anyway, so they can be leveraged in non PowerShell Workflow runbooks as well.