Repository navigation
Invoke-ScriptAnalyzer outputs a warning on manifests that use ModuleToProcess #196
Description
Activity
Thanks Kirk Munro (@KirkMunro), we recently added this AvoidUsingDeprecatedManifestField rule and I think the two scenarios you describe make sense. We want to encourage more people use latest version of PowerShell and maybe it is a better idea to tell users that there is a PowerShell version requirement when they run script analysis.
Kirk Munro (@KirkMunro) Are you running PSScriptAnalyzer from the PowerShell gallery or building it from this repository?
The warning went away when #138 was closed, but came back in another form with the "AvoidUsingDeprecatedManifestFields" rule.
The real problem is that Test-ModuleManifest writes the warning without taking into account the PowerShell version being targeted by the module manifest.
Francis de la Cerna (@imfrancisd) I'm using my forked version that supports PowerShell 3.0 or later. I fetched the development branch from the source project yesterday, or the day before. And since I'm using that fork (so that I can run it on my laptop which runs Windows 8.1/PowerShell 4 right now), I had to build it myself so that I could do that.
In my case, my modules target PowerShell 3.0 or later, where RootModule is available as a manifest key, but I still prefer using ModuleToProcess so that someone loading these modules on PS2.0 gets a more appropriate and useful error message.
Yuting Chen (@yutingc) Yes, that's something I think would be more valuable, indicating the minimum required version.
Also being discussed in Issue #428
Kirk Munro (@KirkMunro) By now. PowerShell v2.0 has been deprecated officially. Do you agree with closing this issue? I think what we rather need is a rule to warn if someone specifies 1.0 or 2.0 as a minimum PowerShell version.
Agreed. Closing this issue.
Right now for all of my modules I use ModuleToProcess in my manifest rather than the newer RootModule name. Because of this, whenever I invoke Invoke-ScriptAnalyzer against my modules, I see the following warning:
WARNING: The module manifest member 'ModuleToProcess' has been deprecated. Use the 'RootModule' member instead.
This warning is suggesting that I change my manifest to use RootModule instead. While I understand why this warning is there, I think it's too early to suggest people switch to ModuleToProcess for one key reason: you can still invoke PowerShell 2.0 even on Windows 10 with WMF5 by running PowerShell -Version 2.
Why does that matter? Because RootModule was only added in PowerShell 3.0, and if you try to import a module that has the RootModule key in the manifest in PowerShell 2.0 you get a completely different experience than if you try to import a module that requires a higher version of PowerShell but that has the ModuleToProcess key in its manifest. In the former scenario, users get an error that seems to indicate the module itself has a problem, pointing at some unknown RootModule key in the manifest. That is a really poor user experience. In the latter scenario, users get an error that properly indicates that the PowerShell version for the current session does not meet the minimum requirements for the module. That user experience is exactly what I want for users of my modules, and that is exactly the type of error I hope they get from any module that they try to open in PowerShell 2.0 that requires a later version (unless, of course, those modules require the use of other new manifest keys that don't have an equivalent in PowerShell 2.0).
The latter scenario is much better for the community, and since even with Windows 10/WMF5 users may open PowerShell 2.0, for modules that require PowerShell 3.0 or later I think it's a better practice to stick with ModuleToProcess as the key that identifies what module will be processed when the manifest is loaded. Only when PowerShell 2.0 is really out of sight/out of mind should this warning start appearing so that manifests are updated to use the new key name.