packages.json in NPM (NodeJS in general) supports prefixes in the version string to specify a minimum required with minor and minor/patch versions being a variable. For example,

The tilde matches the most recent minor version (the middle number). ~1.2.3 will match all 1.2.x versions but won't match 1.3.0.

The caret provides better flexibility. It will refer to the most recent major version (the first number). ^1.2.3 will match any 1.x.x release including 1.3.0, but will hold off on 2.0.0.

Also, an asterisk (*) indicates that the latest version of the module is needed.

Implementing this type of version specification in PowerShell module manifest will help enable flexibility with regards to downloading required modules.

I am trying to update Pester on Windows 2016 to 4.x because the preshipped Pester 3.4.0 emits a note about the depreciation of the -quiet switch when I use the quiet switch. This get's scooped into stdout when executing via AWS SSM remote commands. Version 3.x complains it does not understand "-Show None".

I want to update to 4.x - in which I ran into all the problems documented here: https://github.com/OneGet/oneget/issues/215

But ended up with "Install-module pester -force -SkipPublisherCheck.

So far so bad, but when I go to remove the 3.4.0 version (with admin rights) from: 'c:\program files\windowspowershell\modules\pester\3.4.0' I get errors because only TrustedInstaller has permissions.

If this scenario wasn't horrible enough, putting preinstalled modules under Windows Resource Protection really throws it over the top.

Could someone please make sure that preinstalled modules can be *replaced* cleanly? Or don't preinstall them?

Steps to reproduce:

1. Install WMF5 RTM on a fresh Windows 2012 R2 system
2. Open an Administrator PS prompt and run "Install-Module Pester -Force"

Expected result: The -Force parameter causes the NuGet client to be installed without user intervention.

Actual result: The following message is displayed:

NuGet-anycpu.exe is required to continue.
PowerShellGet requires NuGet-anycpu.exe to interact with NuGet based galleries. NuGet-anycpu.exe must be available in
'C:\Program Files\PackageManagement\ProviderAssemblies' or
'C:\Users\Administrator\AppData\Local\PackageManagement\ProviderAssemblies'. For more information about NuGet provider,
see http://OneGet.org/NuGet.html. Do you want PowerShellGet to download NuGet-anycpu.exe now?
[Y] Yes [N] No [S] Suspend [?] Help (default is "Y"):

The MSDN documentation for $PSCmdlet.ShouldContinue (https://msdn.microsoft.com/en-us/library/ms568259%28v=vs.85%29.aspx) states "Cmdlets calling ShouldContinue should also implement a Force parameter that allows the cmdlet to bypass these calls. If this is not done, it will be difficult to use the cmdlet from scripts and noninteractive hosts." I'm trying to use Install-Module from an automated setup script on a fresh machine, and this prompt causes the script to hang.

Workaround: Before using Install-Module for the first time, run the following command to fetch NuGet-anycpu.exe (this is what Install-Module is doing internally):

PackageManagement\Get-PackageProvider -Name NuGet -Force

In order to register external module dependencies (dependencies living in another repository), the name has to be registered in a string array property within the PSData Hashtable property in the PrivateData section in the psd1 manifest like so for registering module 'psFtp':

PrivateData = @{
PSData = @{
# ExternalModuleDependencies
ExternalModuleDependencies = @('psFtp')
}
} # End of PrivateData hashtable

However, the new-modulemanifest doesn't have an -ExternalModuleDepencies parameter, nor is it possible to register externalmoduledependencies like so:

-PrivateData @{ PSData = @{ ExternalModuleDependencies = @('psFtp') } }

Which from a client perspective of the the existing new-modulemanifest api, would be an intuitive way of setting ExternalModuleDependencies.

Suggestion is:
Either make -ExternalModuleDependencies available as parameter or let the processing of the -PrivateData arguments handle nested hashtables (such as PSData in this case).

Update-ScriptFileInfo only has a couple of mandatory fields. However when you leave them blank the cmdlet returns errors from the validation.

The variable cannot be validated because the value is not a valid value for the CompanyName variable.
The variable cannot be validated because the value is not a valid value for the Copyright variable.
The variable cannot be validated because the value $null is not a valid value for the RequiredModules variable.
The variable cannot be validated because the value $null is not a valid value for the ExternalModuleDependencies variable.
The variable cannot be validated because the value $null is not a valid value for the RequiredScripts variable.
The variable cannot be validated because the value $null is not a valid value for the ExternalScriptDependencies variable.
The variable cannot be validated because the value $null is not a valid value for the Tags variable.
The variable cannot be validated because the value $null is not a valid value for the ProjectUri variable.
The variable cannot be validated because the value $null is not a valid value for the LicenseUri variable.
The variable cannot be validated because the value $null is not a valid value for the IconUri variable.
You cannot call a method on a null-valued expression.

This can be reproduced by running the example from msdn.

New-ScriptFileInfo -Path "\temp\temp-scriptfile.ps1" -Version 1.0 -Author "pattif@contoso.com" -Description "my test script file description goes here"

Update-ScriptFileInfo -Path "\temp\temp-scriptfile.ps1" -Version 2.0 -PassThru

currently it is not possible to specify RequiredModules for a script published to a repository.
This is awkward as it is quite likely for simple scripts to have a dependency on a module.

The goal would be for the module to be installed automatically during install-Script; using the same logic and conditions as the a REQUIREDSCRIPT
1) Interestingly there appears to be (partial) logic to test for RequiredModules, however this always fails as a .Name addtibute of the module cannot be found.
and the syntax used in modules :
.RequiredModules @{ModuleName = 'foo'; GUID = '1234565-2784-48bf-af15-70ba837a64d0'; ModuleVersion = '3.5'; }
is not parsed correctly, and is just stored as a string

This appears to be either a parsing bug, or an incomplete implementation

2) it is possible to specify EXTERNALMODULEDEPENDENCIES, but that is a partial substitute as it does not perform the installation of the module.

This is possible for a

Currently the Module cmdlets apply standard nuget logic to referenced modules (download as needed, apply version restrictions, etc.), but not to binaries referenced by a module (and their dependencies).

This leads to module authors needing to package all referenced binaries (and dependency chains) in the module (e.g., on psgallery). This is an anti-pattern. This is why nuget exists. Aside from version control madness, this creates potential legal issues for module authors if they have a 3rd party binaries in their dependency chain. Now they could be "distributing" 3rd party code which is a very different matter from referencing 3rd party code.

Repro setup

The following path exists:
~\Documents\WindowsPowerShell

Windows 10 Enterprise with the following PSVersionTable:
PS C:\> $PSVersionTable

Name Value
---- -----
PSVersion 5.0.10586.122
PSCompatibleVersions {1.0, 2.0, 3.0, 4.0...}
BuildVersion 10.0.10586.122
CLRVersion 4.0.30319.42000
WSManStackVersion 3.0
PSRemotingProtocolVersion 2.3
SerializationVersion 1.1.0.1

PS C:\> [Environment]::GetFolderPath("MyDocuments")
C:\Users\JanEgil\Documents

PS C:\> $env:USERPROFILE
C:\Users\JanEgil

Repro steps

Run Install-Script -Name Test-RPC -Scope CurrentUser
~\Documents\WindowsPowerShell\Scripts\Test-RPC.ps1 is created, but the following error occurs:
PS C:\> Install-Script -Name Test-RPC -Scope CurrentUser
PackageManagement\Install-Package : Could not find a part of the path ~\Documents\WindowsPow
erShell\Scripts\InstalledScriptInfos\Test-RPC_InstalledScriptInfo.xml'.
At C:\Program Files\WindowsPowerShell\Modules\PowerShellGet\1.0.0.1\PSModule.psm1:2693 char:21
+ ... $null = PackageManagement\Install-Package @PSBoundParameters
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : OpenError: (Microsoft.Power....InstallPackage:InstallPackage) [Install-Packag
e], Exception
+ FullyQualifiedErrorId : FileOpenFailure,Microsoft.PowerShell.Commands.OutFileCommand,Microsoft.PowerS
****.PackageManagement.Cmdlets.InstallPackage

If I delete the downloaded ps1-file and create ~\Documents\WindowsPowerShell\Scripts\InstalledScriptInfos before running Install-Script -Name Test-RPC -Scope CurrentUser it runs without issues.

Install-PackageProvider cannot retrieve the list of available providers if the machine doesn't have direct access to the internet.

PS C:\Windows\system32> Install-PackageProvider -Name NuGet -MinimumVersion 2.8.5.201 -Force
WARNING: Unable to download the list of available providers. Check your internet connection.
Install-PackageProvider : No match was found for the specified search criteria for the provider 'NuGet'. The package
provider requires 'PackageManagement' and 'Provider' tags. Please check if the specified package has the tags.
At line:1 char:1
+ Install-PackageProvider -Name NuGet -MinimumVersion 2.8.5.201 -Force
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : InvalidArgument: (Microsoft.Power...PackageProvider:InstallPackageProvider) [Install-Pac
kageProvider], Exception
+ FullyQualifiedErrorId : NoMatchFoundForProvider,Microsoft.PowerShell.PackageManagement.Cmdlets.InstallPackagePro
vider

How to reproduce:
1. Setup a network completely separate from the internet.
2. Setup an HTTP-proxy in that network as following:
2.1. The machine with HTTP-proxy has 2 network interfaces: 1 connected to a LAN and another one - to the internet.
2.2. Configure the proxy in a way to require authentication, not allowing anonymous connections. Configure Kerberos authentication.
2.3. Allow access to the internet via the proxy for AD user accounts only, not for the computer ones.
3. Publish the proxy with WPAD.
4. Use Group Policy to configure Internet Explorer throughout the network to use WPAD as a source of proxy settings.
5. Try access the internet (http://example.com) via Internet Explorer - everything works fine.
6. Launch PowerShell console as an administrator, using AD account allowed to access internet via the proxy.
7. Try to download NuGet provider using Install-PackageProvider cmdlet - you receive an error shown above.