-
Notifications
You must be signed in to change notification settings - Fork 14
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Invoke-DscResource cmdlet throws an exception when using class-based DSC Resource, when module path contains a space #73
Comments
/cc @TravisEz13 for comments. |
@KristiyanGK Can you run |
@TravisEz13 This is the result I get by running |
@KristiyanGK Unfortunately, this lives in a private repo. I think I should transfer this issue to that repo, which will make it invisible to you. After, I do so, feel free to file a new issue here, and mention me and I'll link them. Does that sound fair? Hopefully, the other repo will become public, at least for issue tracking soon enough. |
It appears to me (having done some debugging with VS Code) that (part of) the bug is here: $listPSModuleFolders = $env:PSModulePath.Split(":") It's splitting on |
Yup... it should be using |
I think what I mentioned in my previous comment is actually an unrelated problem. Having done a lot more debugging, I think I've tracked the problem to $iss = [System.Management.Automation.Runspaces.InitialSessionState]::CreateDefault2()
$powershell = [PowerShell]::Create($iss)
$script = @"
using module $path
Write-Host -Message ([$type]::new | out-string)
return [$type]::new()
"@
$null= $powershell.AddScript($script)
$dscType=$powershell.Invoke() | Select-object -First 1 Essentially, it's creating an entirely new PowerShell session as if it were a host application, and then using it to execute a script with a From one perspective, it seems like it would be a lot easier to just use a script block rather than this hosting-PowerShell-in-PowerShell craziness, but the actual cause of the problem appears to be that the path is unquoted in the script, so, e.g. I think the best fix for this is probably the long-overdue engine modifications to make $script = @"
using module "$path"
return [$type]::new()
"@
$dscType = & ([ScriptBlock]::Create($script)) or similar should be a good fix. Testing it on my machine seems to indicate that it works. I would put in a PR, but as @TravisEz13 said above, |
I should point out that, at least in my case, leaving the PowerShell-in-PowerShell thing in place and just fixing the quotes led to a bunch of other problems and crashed my script; it works fine with the script block. |
Hi, how is the plan here ? Also run into this |
This issue continues in the current version of Does the PowerShell team plan to address this issue at some point in 2022? |
Any Update on this issue ? |
When using a custom class-based DSC resource, the **Invoke-DscResource **cmdlet fails.
The issue seems to be in the function Invoke-DscClassBasedResource in the PSDesiredStateConfiguration.psm1 of the PSDesiredStateConfiguration module:
When $path is a string with white spaces for example: C:\My Modules\MyModule.psd1 the path gets cut off at the first space and results in C:\My. This leads to an error when trying to use the module, due to the fact that the path is invalid.
Steps to reproduce
Expected behavior
Actual behavior
Environment data
$psversiontable info
PSVersion | 7.0.3
PSEdition | Core
GitCommitId | 7.0.3
OS | Microsoft Windows 10.0.18363
Platform | Win32NT
PSCompatibleVersions| {1.0, 2.0, 3.0, 4.0…}
PSRemotingProtocolVersion | 2.3
SerializationVersion |1.1.0.1
WSManStackVersion |3.0
The text was updated successfully, but these errors were encountered: