PowerShell / PSDscResources

MIT License
129 stars 53 forks source link

Script: $using:Key variable in a script receives the wrong value #171

Open NReilingh opened 4 years ago

NReilingh commented 4 years ago

Details of the scenario you tried and the problem that is occurring

When a variable in configuration scope named Key is used inside the GetScript, SetScript, or TestScript properties of the Script resource by way of the using: annotation, it is compiled into the .mof file with a value of Credential regardless of what the variable value in the configuration scope actually is.

See also this Gist: https://gist.github.com/NReilingh/f503c556f45f032dd01f9de82f4f0ae0

This works the same way whether importing PSDesiredStateConfiguration or PSDscResources 2.12.0.0.

I don't know if the logic that generates the MOF file is in this repo or not, or whether that would indicate an issue with a different part of DSC, or perhaps a documentation lapse.

The DSC configuration that is used to reproduce the issue (as detailed as possible)

Configuration TestConfig
{
    Import-DscResource -ModuleName PSDscResources -Name Script

    $Key = "My Value"

    Node localhost
    {
        Script TestScript
        {
            GetScript = {
                Write-Verbose "`$Key value is $using:Key"
                # NoOp
            }
            TestScript = {
                Write-Verbose "`$Key value is $using:Key"

                if ($using:Key -eq 'Credential') {
                    return $false
                } else {
                    return $true
                }
            }
            SetScript = {
                Write-Verbose "`$Key value is $using:Key"
                # NoOp
            }
        }
    }
}

The operating system the development system is running

OsName               : Microsoft Windows 10 Pro
OsOperatingSystemSKU : 48
OsArchitecture       : 64-bit
WindowsVersion       : 1903
WindowsBuildLabEx    : 18362.1.amd64fre.19h1_release.190318-1202
OsLanguage           : en-US
OsMuiLanguages       : {en-US}

Version and build of PowerShell the target node is running

Name                           Value
----                           -----
PSVersion                      5.1.18362.145
PSEdition                      Desktop
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0...}
BuildVersion                   10.0.18362.145
CLRVersion                     4.0.30319.42000
WSManStackVersion              3.0
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1

Version of the DSC module that was used ('dev' if using current dev branch)

2.12.0.0

mhendric commented 4 years ago

Looks like this is reproducible. Looks like the workaround is pretty simple (don't use a variable named $Key), however this should probably be documented. If we want to fix this behavior, I'm not sure if we should do it here, or only do it in xPSDesiredStateConfiguration. @PlagueHO and @johlju , what's your thoughts on this?

MOF output With $Key Variable:

/*
@TargetNode='localhost'
@GeneratedBy=Mike
@GenerationDate=09/25/2019 09:57:19
@GenerationHost=DP7510
*/

instance of MSFT_ScriptResource as $MSFT_ScriptResource1ref
{
ResourceID = "[Script]TestScript";
 GetScript = "$Key ='Credential'\n\n                Write-Verbose \"`$Key value is $Key\"\n                # NoOp\n            ";
 TestScript = "$Key ='Credential'\n\n                Write-Verbose \"`$Key value is $Key\"\n\n                if ($Key -eq 'Credential') {\n                    return $false\n                } else {\n                    return $true\n                }\n            ";
 SourceInfo = "D:\\Test.ps1::9::9::Script";
 SetScript = "$Key ='Credential'\n\n                Write-Verbose \"`$Key value is $Key\"\n                # NoOp\n            ";
 ModuleName = "PSDscResources";
 ModuleVersion = "2.12.0.0";

 ConfigurationName = "TestConfig";

};
instance of OMI_ConfigurationDocument

                    {
 Version="2.0.0";

                        MinimumCompatibleVersion = "1.0.0";

                        CompatibleVersionAdditionalProperties= {"Omi_BaseResource:ConfigurationName"};

                        Author="Mike";

                        GenerationDate="09/25/2019 09:57:19";

                        GenerationHost="DP7510";

                        Name="TestConfig";

                    };

MOF Output With $NotKey Variable (instead of $Key):

/*
@TargetNode='localhost'
@GeneratedBy=Mike
@GenerationDate=09/25/2019 09:56:12
@GenerationHost=DP7510
*/

instance of MSFT_ScriptResource as $MSFT_ScriptResource1ref
{
ResourceID = "[Script]TestScript";
 GetScript = "$NotKey ='My Value'\n\n                Write-Verbose \"`$NotKey value is $NotKey\"\n                # NoOp\n            ";
 TestScript = "$NotKey ='My Value'\n\n                Write-Verbose \"`$NotKey value is $NotKey\"\n\n                if ($NotKey -eq 'Credential') {\n                    return $false\n                } else {\n                    return $true\n                }\n            ";
 SourceInfo = "D:\\Test.ps1::9::9::Script";
 SetScript = "$NotKey ='My Value'\n\n                Write-Verbose \"`$NotKey value is $NotKey\"\n                # NoOp\n            ";
 ModuleName = "PSDscResources";
 ModuleVersion = "2.12.0.0";

 ConfigurationName = "TestConfig";

};
instance of OMI_ConfigurationDocument

                    {
 Version="2.0.0";

                        MinimumCompatibleVersion = "1.0.0";

                        CompatibleVersionAdditionalProperties= {"Omi_BaseResource:ConfigurationName"};

                        Author="Mike";

                        GenerationDate="09/25/2019 09:56:12";

                        GenerationHost="DP7510";

                        Name="TestConfig";

                    };
johlju commented 4 years ago

I suggest document this issue. I’m not seeing this as a bug but more an enhancement, and as per latest Community Call enhancements should be added to xPSDesiredStateConfiguration. But I think it would be okay to update the README.md here to document this.

/cc @gaelcolas

NReilingh commented 4 years ago

I do think it's a little weird that the value of $Key ends up being "Credential" and not something else. Whether or not it should be changed, do we know where the code is that actually produces this behavior? Seems plausible that something is "leaking" that shouldn't be.

johlju commented 4 years ago

Since it happens at compile time it has to be in the PowerShell code? It’s not in the resource code :thinking: so, I don’t think it’s a bug here. But it looks like a bug when PowerShell is parsing the Configuration keyword?

johlju commented 4 years ago

Do the same thing happen in PowerShell 7-preview4? (Or latest preview)

NReilingh commented 4 years ago

@johlju Just tested on 7.0.0-preview.4 — same behavior.

johlju commented 4 years ago

Then I suggest to submit an issue to the PowerShell repo to see if it can be resolved. If we are lucky it can be back-ported to Windows PowerShell, but wouldn’t give my hopes up on that.

johlju commented 4 years ago

To close this issue I suggest to send in PR that changes the documentation to inform of this issue and to avoid using that variable name.