SaveDscDependency throws error on Linux

[bgelens]

Steps to reproduce

Run with version 1.18.0 using SaveDscDependency switch on an arbitrary ps1 file (doesn't have to be a configuration) on Linux (I'm running Ubuntu 18.04 on WSL).

It works fine on Windows when using PowerShell 6.2.

Invoke-ScriptAnalyzer -Path '/mnt/c/justascript.ps1' -SaveDscDependency

Expected behavior

Just run without an issue

Actual behavior

Invoke-ScriptAnalyzer : Value cannot be null.
Parameter name: path1
At line:1 char:1
+ Invoke-ScriptAnalyzer -Path '/mnt/c/Projects/GO-M-Automation/Src/Prod ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo          : NotSpecified: (:) [Invoke-ScriptAnalyzer], ArgumentNullException
+ FullyQualifiedErrorId : System.ArgumentNullException,Microsoft.Windows.PowerShell.ScriptAnalyzer.Commands.InvokeScriptAnalyzerCommand

PSMessageDetails      :
Exception             : System.ArgumentNullException: Value cannot be null.
                        Parameter name: path1
                           at System.IO.Path.Combine(String path1, String path2)
                           at
                        Microsoft.Windows.PowerShell.ScriptAnalyzer.Generic.ModuleDependencyHandler..ctor(Runspace
                        runspace, String moduleRepository, String tempPath, String localAppDataPath)
                           at Microsoft.Windows.PowerShell.ScriptAnalyzer.Commands.InvokeScriptAnalyzerCommand.ProcessR
                        ecord()
                           at System.Management.Automation.Cmdlet.DoProcessRecord()
                           at System.Management.Automation.CommandProcessor.ProcessRecord()
TargetObject          :
CategoryInfo          : NotSpecified: (:) [Invoke-ScriptAnalyzer], ArgumentNullException
FullyQualifiedErrorId : System.ArgumentNullException,Microsoft.Windows.PowerShell.ScriptAnalyzer.Commands.InvokeScriptA
                        nalyzerCommand
ErrorDetails          :
InvocationInfo        : System.Management.Automation.InvocationInfo
ScriptStackTrace      : at <ScriptBlock>, <No file>: line 1
PipelineIterationInfo : {}

Environment data

> $PSVersionTable
Name                           Value
----                           -----
PSVersion                      6.2.0
PSEdition                      Core
GitCommitId                    6.2.0
OS                             Linux 4.4.0-43-Microsoft #1-Microsoft Wed Dec 31 14:42:53 PST 2014
Platform                       Unix
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0…}
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1
WSManStackVersion              3.0

> (Get-Module -ListAvailable PSScriptAnalyzer).Version | ForEach-Object { $_.ToString() }
1.18.0
1.17.1

[arpitjain099]

Agreed with Ben

[bergmeister]

Sorry, I've been busy lately, I plan to have a look at this possibly by next week

[arpitjain099]

Thanks @bergmeister . Looking forward to it.

[bergmeister]

I can repro this and have a local fix ready. Will open a PR in the next days. The problem is this line here that is Windows specific as Linux does not have an APPDATA environment variable. The fix will be to replace it with something like ? Environment.GetEnvironmentVariable(RuntimeInformation.IsOSPlatform(OSPlatform.Windows) ? "LOCALAPPDATA" : "HOME") but I need to write a failing test now first and see if downloading an actual DSC module works end to end as well in Linux. I just ran the ModuleDependencyHandler.tests.ps1 tests (that are currently only run on Windows in CI) on WSL and only 2 of 11 tests pass after the first fix, therefore I expect there to be quite a bit more effort to get it fully working. The state of the code at the moment looks like using this switch was not designed for Linux at the time when it was written (understandably) so I'd rather classify this as a feature that is not implemented/supported yet but I am happy to start working a bit on it and see where it goes. I might get it easily to work but it also might be a bigger item, it is hard to tell at the moment. UPDATE: After some more fixes (e.g. this), I now have 4 tests passing 🧪 now locally.
Can any of you say how well PowerShell Core already supports DSC on Linux? Why do you want to use this switch on Linux?

[bgelens]

Thanks for all the great work @bergmeister!

To answer your question, It is not that we are using DSC on Linux. It's that we want our CI QA tests to pass on all ps files in the repo (some of them being DSC configurations) and off course script analyzer is a major part of the QA. QA tests are targeted to run both on Windows and Linux in our Azure DevOps environment. This is also done to assure every dev in our project can validate the base QA tests on their own system wether it's mac, win or linux.

That being said, we could opt for a more granular approach where we check every file individually to see if it's a DSC configuration and don't test when running on Linux. Right now we go in by storm and have a generic set of parameters for Invoke-ScriptAnalyzer for every file we check.

[bergmeister]

You're welcome @bgelens
Just that you are aware: PSSA is not 100% static and only 90% of the functionality is available on all PS versions/platforms:

• PSSA makes e.g. Get-Command calls for it's analysis, therefore service will e.g be flagged up on Windows as an implicit alias to Get-Service (a PowerShell easter egg: if a command cannot be found by its name, PS will try to pre-pend Get- and execute that command if it can be found) but not on Linux where service is a binary.
• The mentioned difference in feature set is mainly due to either PS not providing certain features on certain versions (e.g. DSC was only added in v5) or the underling ,Net Framework. For example, .Net Core does not have a Pluralization API and therefore the PSUseSingularNouns rule is not available in PowerShell Core.
  The general guidance is to run PSSA on a PS version and platform where the scripts are likely to be run and if possible use at least PS version 5/6 (PS v3 and PS v4 are technically supported by PSSA v 1.x but have a reduced feature set due to PS not providing certain APIs and v3 might even have some bugs as we do not have CI tests run on it; we are thinking of dropping support for PS v3/4 in PSSA 2.0 btw)