Psscriptanalyzer: Should the 'Microsoft.Windows.PowerShell.ScriptAnalyzer' namespace/assembly names be renamed to 'Microsoft.PowerShell.ScriptAnalyzer' ?

[bergmeister]

Question as per title. This would be a breaking change. What do you think @JamesWTruher

[kilasuit]

Personally I cannot see any benefit for this change, are there any benefits that are possibly hidden behind this seeming to be a relatively simple suggested change?

[bergmeister]

Although one can already use PSSA on non Windows systems or PowerShell Core, there are some bugs that will be squashed as CI for Linux, MacOS and pwsh is going to be introduced to be truly cross platform and support it (at the moment all CI tests are not green on those systems). PowerShell Core did a scrub for 'Windows' strings as things got more serious and therefore I am questioning if we need to do a rename here as well. At worst, it could be slightly irritating to non Windows users but not an issue. Since I assume that most consumers use the cmdlets rather than the public API methods (even the vscode powershell extension does it now), it should not be too much of a breaking change.
Different people (and MS) will have different opinions, therefore I opened the issue to gather opinions and be truly open about it and not have upset people when it is too late.

[LaurentDardenne]

This may seem trivial, but changing these names would be more consistent when reading the code, this would make it possible to use the word 'Windows' for parts of code specific to this operating system.

[JamesWTruher]

In my mind, it really depends on the users of the assemblies. My understanding is that it is possible to embed PSSA into other things and rely on the API surface rather than the execution of the cmdlet from within a PowerShell session. If this is the case, then this sort of change would be a rather sizeable breaking change, and this change would need to be looked at in that light. If this isn't the case, and folks aren't using the API space, then it really doesn't matter what namespace we use. My _personal_ preference is to change the namespace because it's too small - PSSA is much larger than just Windows.
@joeyaiello @tylerl0706 for additional input

[bergmeister]

As far as I know, the PowerShellEditorServices extension was changed (many months ago) to call Invoke-ScriptAnalyzer directly from pwsh (some of the issues were due to PSSA hanging on and accumulating memory (issue 660) due to the static Helper class). Not sure about other integrators though

[TylerLeonhardt]

As @bergmeister said, PSES uses Invoke-ScriptAnalyzer so there will be no issues there.

cc @daviwil, @rkeithhill, @seeminglyscience, @rjmholt

[bergmeister]

Actually, by looking at script based Rules, like e.g. this one, it turns out that a namespace renaming would be much more breaking than just the assembly rename because a script based rule needs to create and return an object of type Microsoft.Windows.PowerShell.ScriptAnalyzer.Generic.DiagnosticRecord at the end of the day. Changing the namespace would at least be easily fixable with a simple search&replace imho, where we could even provide an upgrade helper script.
Someone needs to make a decision if we want this breaking change or not. @joeyaiello @JamesWTruher

[SeeminglyScience]

Changing the namespace would at least be easily fixable with a simple search&replace imho, where we could even provide an upgrade helper script.

That depends, if they want to keep compatibility with older versions of PSSA they'd either have to add using namespace statements for both namespaces or test for PSSA version and change type name accordingly.

Also, I remember seeing somewhere that you could point CustomRulePath to a compiled assembly. I specifically remember seeing at least one issue regarding it's use, so while there probably aren't a ton of folks creating them, I don't think it's zero.