locked
Where-Object fails with "Parameter set cannot be resolved using the specified named parameters." RRS feed

  • Question

  • This may not have an obvious answer, might totally be an error on my side, but are there any known limitations with the Where-Object and Azure Automation Runbooks?

    I invoke a webservice and that part works just fine, but when I try to filter via Where-Object, works just fine locally but via Azure automation runbook the Where-Object fails with "Parameter set cannot be resolved using the specified named parameters."

    This is the piece of code that fails

    $publicRepos =  $repos | Where-Object {$_.is_private -ne "True"}

    If I output the $repos I get correct objects in the Runbook output

    scm               : git
    has_wiki          : True
    last_updated      : 2013-11-03T16:37:33.114
    no_forks          :
    created_on        : 2013-03-29T12:19:24.446
    owner             : wcom
    logo              : https://bitbucket-assetroot.s3.amazonaws.com/c/photos/2013/Mar/29/wcom-public-logo-2620097946-3_avatar.png
    email_mailinglist :
                        info@wcom.se
    is_mq             : False
    size              : 7727532
    read_only         : False
    fork_of           :
    mq_of             :
    state             : available
    utc_created_on    : 2013-03-29 11:19:24+00:00
    website           : http://www.wcom.se/
    description       :
    has_issues        : True
    is_fork           : False
    slug              : wcom-public
    is_private        : False
    name              : wcom-public
    language          : c#
    utc_last_updated  : 2013-11-03 15:37:33+00:00
    email_writers     : True
    no_public_forks   : False
    creator           :
    resource_uri      : /1.0/repositories/wcom/wcom-public
    

    If I remove the Where-Object everything works, but obviously get to many items.

    If I do a foreach and do the Where "manually" it runs just fine both in runbook locally and on Azure, i.e. something like below works flawlessly using the same "properties":

        $PublicCount = 0
        $PrivateCount = 0
        foreach($repo in $repos)
        {
            if ($repo.is_private -eq "True")
            {
                $PrivateCount++
            }
            else
            {
                $PublicCount++
            }
        }

    Regards,
    /Mattias

    Wednesday, April 9, 2014 5:29 PM

Answers

  • Hi Mattias,

    This actually has nothing to do with Azure Automation runbooks specifically -- the issue is that Powershell Workflow does not support positional parameters while regular PowerShell does.

    While this will work in regular PowerShell:

    function fooFunc {
        $repos = @(
            @{
                "name" = "Repo1";
                "is_private" = "True"
            },
         
            @{
                "name" = "Repo2";
                "is_private" = "False"
            }   
        )
        
        $publicRepos =  $repos | Where-Object {$_.is_private -ne "True"}
    
        $publicRepos
    }

    It will not compile in PowerShell Workflow (in PowerShell onprem or in an Azure Automation runbook):

    workflow fooWorkflow {
        $repos = @(
            @{
                "name" = "Repo1";
                "is_private" = "True"
            },
         
            @{
                "name" = "Repo2";
                "is_private" = "False"
            }   
        )
        
        $publicRepos =  $repos | Where-Object {$_.is_private -ne "True"}
    
        $publicRepos
    }

    The way to get this working it to specify the parameter name for the filter script you are passing to where-object:

    workflow fooWorkflow {
        $repos = @(
            @{
                "name" = "Repo1";
                "is_private" = "True"
            },
         
            @{
                "name" = "Repo2";
                "is_private" = "False"
            }   
        )
        
        $publicRepos =  $repos | Where-Object -FilterScript {$_.is_private -ne "True"}
    
        $publicRepos
    }

    Summary: Make sure the stuff you put in runbooks is valid PowerShell Workflow -- if its not, it won't work in a runbook :)

    For more information on the differences between PowerShell and PowerShell Workflow, take a look at http://technet.microsoft.com/en-us/magazine/dn151046.aspx


    • Proposed as answer by Joe Levy_ Wednesday, April 9, 2014 7:18 PM
    • Edited by Joe Levy_ Wednesday, April 9, 2014 7:21 PM
    • Marked as answer by Joe Levy_ Wednesday, April 9, 2014 7:21 PM
    Wednesday, April 9, 2014 7:17 PM

All replies

  • Hi Mattias,

    This actually has nothing to do with Azure Automation runbooks specifically -- the issue is that Powershell Workflow does not support positional parameters while regular PowerShell does.

    While this will work in regular PowerShell:

    function fooFunc {
        $repos = @(
            @{
                "name" = "Repo1";
                "is_private" = "True"
            },
         
            @{
                "name" = "Repo2";
                "is_private" = "False"
            }   
        )
        
        $publicRepos =  $repos | Where-Object {$_.is_private -ne "True"}
    
        $publicRepos
    }

    It will not compile in PowerShell Workflow (in PowerShell onprem or in an Azure Automation runbook):

    workflow fooWorkflow {
        $repos = @(
            @{
                "name" = "Repo1";
                "is_private" = "True"
            },
         
            @{
                "name" = "Repo2";
                "is_private" = "False"
            }   
        )
        
        $publicRepos =  $repos | Where-Object {$_.is_private -ne "True"}
    
        $publicRepos
    }

    The way to get this working it to specify the parameter name for the filter script you are passing to where-object:

    workflow fooWorkflow {
        $repos = @(
            @{
                "name" = "Repo1";
                "is_private" = "True"
            },
         
            @{
                "name" = "Repo2";
                "is_private" = "False"
            }   
        )
        
        $publicRepos =  $repos | Where-Object -FilterScript {$_.is_private -ne "True"}
    
        $publicRepos
    }

    Summary: Make sure the stuff you put in runbooks is valid PowerShell Workflow -- if its not, it won't work in a runbook :)

    For more information on the differences between PowerShell and PowerShell Workflow, take a look at http://technet.microsoft.com/en-us/magazine/dn151046.aspx


    • Proposed as answer by Joe Levy_ Wednesday, April 9, 2014 7:18 PM
    • Edited by Joe Levy_ Wednesday, April 9, 2014 7:21 PM
    • Marked as answer by Joe Levy_ Wednesday, April 9, 2014 7:21 PM
    Wednesday, April 9, 2014 7:17 PM
  • Superb, worked as expected👍, thanks for the resource!
    Wednesday, April 9, 2014 7:36 PM
  • Thanks for your feedback.

    instead of where condition i am now looping and adding if condition

    Wednesday, October 15, 2014 8:49 AM