ironmansoftware / powershell-universal

Issue tracker for PowerShell Universal
https://powershelluniversal.com
35 stars 2 forks source link

[error] Unable to find type [Microsoft.ActiveDirectory.Management.ADAccount]. #3589

Open mikedhanson opened 3 weeks ago

mikedhanson commented 3 weeks ago

Version

4.3.4

Severity

Low

Environment

msi

Steps to Reproduce

I am running into a weird PSU thing where I have a script that has a param with a type of " [Microsoft.ActiveDirectory.Management.ADAccount]" and when I run the script it throws the following error

[error] Unable to find type [Microsoft.ActiveDirectory.Management.ADAccount].

However, if I wrap that param block in a function and do the AD import before that function call it works. I am running this in a external pwsh environment.

Does not work

[CmdletBinding()]
param (
    [Parameter(ValueFromPipeline = $true)]
    [Microsoft.ActiveDirectory.Management.ADAccount]
    $UserAccount
) 

Works


Import-Module ActiveDirectory

function test {
    [CmdletBinding()]
    param (
        [Parameter(ValueFromPipeline = $true)]
        [Microsoft.ActiveDirectory.Management.ADAccount]
        $UserAccount
    )
    return $UserAccount.SamAccountName
}

Get-aduser validuser | test

This also works when you use #requies

#requires -Module ActiveDirectory

[CmdletBinding()]
param (
    [Parameter(ValueFromPipeline = $true)]
    [Microsoft.ActiveDirectory.Management.ADAccount]
    $UserAccount
)

Expected behavior

Shouldn't PSU import the module based on its type? Could we have a section in the script? PS1 settings to specify which modules this script requires?

Actual behavior

[error] Unable to find type [Microsoft.ActiveDirectory.Management.ADAccount].

Additional Environment data

No response

Screenshots/Animations

No response

adamdriscoll commented 3 weeks ago

That's a good question. I don't know why this would work in a regular prompt and not PSU unless they are doing some other kind of special assembly auto loading. It's pretty clear that the assembly just isn't loaded so it doesn't know what the type is but I've never actually noticed this with non-custom DLLs. I have noticed this with PSU DLLs themself. We need to ensure they are loaded.

You could add the AD module to the environment's modules section and it will load the module while creating the runspace.