Skip to content

Remove -DotnetFrameworkVersion and -ClrVersion from New-ModuleManifest #18330

New issue
New issue
Closed
Closed
Remove -DotnetFrameworkVersion and -ClrVersion from New-ModuleManifest#18330
Labels
Issue-Enhancementthe issue is more of a feature request than a bugResolution-No ActivityIssue has had no activity for 6 months or moreUp-for-GrabsUp-for-grabs issues are not high priorities, and may be opportunities for external contributorsWG-Cmdletsgeneral cmdlet issues

Description

@SteveL-MSFT
Steve Lee (SteveL-MSFT)
opened on Oct 19, 2022

Summary of the new feature / enhancement

Per MicrosoftDocs/PowerShell-Docs#9328 these members in the module manifest are no longer valid and keeping it can cause confusion on why it's not doing what the author thinks it should be doing.

Proposed technical implementation details (optional)

No response

Activity

  1. Steve Lee (SteveL-MSFT)
    added
    Issue-Enhancementthe issue is more of a feature request than a bug
    WG-Cmdletsgeneral cmdlet issues
    Breaking-Changebreaking change that may affect users
    Needs-TriageThe issue is new and needs to be triaged by a work group.
    on Oct 19, 2022

  2. iSazonov commented on Oct 19, 2022

    @iSazonov
    Ilya (iSazonov)
    on Oct 19, 2022
    Collaborator

    What about ProcessorArchitecture?

    #18320 (comment)

  3. Jaykul commented on Oct 19, 2022

    @Jaykul
    Joel Bennett (Jaykul)
    on Oct 19, 2022
    Contributor

    Proposed technical implementation details (optional)

    The obsolete parameters should be marked obsolete via documentation (and hidden if possible from tab completion) but not removed (since they don't break things, and removing them might break existing scripts).

    Optionally, when a value is provided, the cmdlet can output a warning that these fields don't work correctly in modern PowerShell. NOTE: this is for DotnetFrameworkVersion and CLRVersion which legitimately don't work.

    Finally, I think it would be great if we could not put the commented out text for these in the psd1 (when there's no value passed in to the parameter).

    What about ProcessorArchitecture?

    #18320 (comment)

    Surely there are PowerShell modules that don't/only work on ARM? But I don't know if this one works or not.

    However, at the very least, I think it would be useful to have all the parameters that are rarely used and are complicated to get right ... just not output in the PSD1 unless they have a value. The commented out lines aren't useful. That's at least these:

    • ProcessorArchitecture
    • PowerShellHostName
    • PowerShellHostVersion
    • FileList
    • DefaultCommandPrefix

  4. iSazonov commented on Oct 20, 2022

    @iSazonov
    Ilya (iSazonov)
    on Oct 20, 2022
    Collaborator

    Search results on Windows Server 2019 with RSAT:

    C:\Windows\System32\WindowsPowerShell\v1.0\Modules\BestPractices\BestPractices.psd1:33:CLRVersion = '4.0'
C:\Windows\System32\WindowsPowerShell\v1.0\Modules\DFSR\DFSR.psd1:38:CLRVersion = '4.0'
C:\Windows\System32\WindowsPowerShell\v1.0\Modules\NetSecurity\NetSecurity.psd1:34:    ClrVersion = '4.0'
C:\Windows\System32\WindowsPowerShell\v1.0\Modules\PersistentMemory\PersistentMemory.psd1:31:CLRVersion = '4.0'
C:\Windows\System32\WindowsPowerShell\v1.0\Modules\PSScheduledJob\PSScheduledJob.psd1:17:CLRVersion = '4.0'
C:\Windows\System32\WindowsPowerShell\v1.0\Modules\RemoteDesktop\RemoteDesktop.psd1:41:CLRVersion = '4.0'
C:\Windows\System32\WindowsPowerShell\v1.0\Modules\ScheduledTasks\ScheduledTasks.psd1:9:    ClrVersion = '4.0'
C:\Windows\System32\WindowsPowerShell\v1.0\Modules\ServerManager\ServerManager.psd1:9:CLRVersion = '4.0'
C:\Windows\System32\WindowsPowerShell\v1.0\Modules\Whea\Whea.psd1:36:CLRVersion = '4.0'


C:\Windows\System32\WindowsPowerShell\v1.0\Modules\DFSR\DFSR.psd1:35:DotNetFrameworkVersion = '4.0'


C:\Windows\System32\WindowsPowerShell\v1.0\Modules\AppvClient\AppvClient.psd1:18:ProcessorArchitecture = 'AMD64'

    I also tried to find at least one module with ProcessorArchitecture with a non-empty value on GitHub, but I couldn't.

  5. iSazonov commented on Oct 20, 2022

    @iSazonov
    Ilya (iSazonov)
    on Oct 20, 2022
    Collaborator

    The only place to keep these things for backward compatibility is in the PSD file parser. Elsewhere they can be freely removed.

  6. SteveL-MSFT commented on Nov 2, 2022

    @SteveL-MSFT
    Steve Lee (SteveL-MSFT)
    on Nov 2, 2022
    MemberAuthor

    The @PowerShell/wg-powershell-cmdlets reviewed this and agreed that these members don't serve value and at worst will be misleading to users. Our proposal is to not make a breaking change by removing them now, but make them no-op and emit a warning when used.

  7. Steve Lee (SteveL-MSFT)
    added
    Up-for-GrabsUp-for-grabs issues are not high priorities, and may be opportunities for external contributors
    and removed
    Breaking-Changebreaking change that may affect users
    Needs-TriageThe issue is new and needs to be triaged by a work group.
    on Nov 2, 2022

  8. iSazonov commented on Nov 2, 2022

    @iSazonov
    Ilya (iSazonov)
    on Nov 2, 2022
    Collaborator

    reviewed this and agreed that these members

    What is "these"? Please clarify.

  9. microsoft-github-policy-service commented on Nov 15, 2023

    @microsoft-github-policy-service
    microsoft-github-policy-serviceBot
    on Nov 15, 2023 – with Microsoft GitHub Policy Service
    Contributor

    This issue has not had any activity in 6 months, if this is a bug please try to reproduce on the latest version of PowerShell and reopen a new issue and reference this issue if this is still a blocker for you.

  10. microsoft-github-policy-service commented on Nov 15, 2023

    @microsoft-github-policy-service
    microsoft-github-policy-serviceBot
    on Nov 15, 2023 – with Microsoft GitHub Policy Service
    Contributor

    This issue has not had any activity in 6 months, if this is a bug please try to reproduce on the latest version of PowerShell and reopen a new issue and reference this issue if this is still a blocker for you.

  11. microsoft-github-policy-service
    added
    Resolution-No ActivityIssue has had no activity for 6 months or more
    on Nov 15, 2023

  12. microsoft-github-policy-service commented on Nov 15, 2023

    @microsoft-github-policy-service
    microsoft-github-policy-serviceBot
    on Nov 15, 2023 – with Microsoft GitHub Policy Service
    Contributor

    This issue has not had any activity in 6 months, if this is a bug please try to reproduce on the latest version of PowerShell and reopen a new issue and reference this issue if this is still a blocker for you.

  13. microsoft-github-policy-service commented on Nov 22, 2023

    @microsoft-github-policy-service
    microsoft-github-policy-serviceBot
    on Nov 22, 2023 – with Microsoft GitHub Policy Service
    Contributor

    This issue has been marked as "No Activity" as there has been no activity for 6 months. It has been closed for housekeeping purposes.

  14. microsoft-github-policy-service
    closed this as completedon Nov 22, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Issue-Enhancementthe issue is more of a feature request than a bugResolution-No ActivityIssue has had no activity for 6 months or moreUp-for-GrabsUp-for-grabs issues are not high priorities, and may be opportunities for external contributorsWG-Cmdletsgeneral cmdlet issues

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions