Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

MSFT_PackageManagement: Fix passing switch values in AdditionalParameters #500

Open
wants to merge 5 commits into
base: WIP
Choose a base branch
from

Conversation

jberezanski
Copy link

When a DSC configuration, which uses the PackageManagement resource and attempts to pass provider-specific parameters via AdditionalParameters, is compiled, the parameters dictionary is serialized to MSFT_KeyValuePair objects, which hold a pair of strings. As a consequence, all type information about AdditionalParameters values is lost.

This poses a problem when a provider defines parameters whose types are not implictly convertible from string. Two such common types are [switch] and [bool]. For example, the PowerShellGet provider defines several switch parameters, such as InstallUpdate, AllowClobber or AllowPrereleaseVersions - all of those are quite important. Unfortunately, attempting to pass values to those parameters in a DSC configuration leads to failures, caused by attempts to directly assign a string value to a SwitchParameter.

This pull request solves this problem. Although the PackageManagement resource has no direct access to provider metadata, it can examine the parameters of the cmdlets it intends to call and determine their types. For [switch] and [bool] parameters, the resource parses the string value from AdditionalParameters to a [bool], which is implicitly convertible to [switch].

Example configuration, which fails on 1.4.7 and works after this PR:

configuration TestSwitches
{
    Import-DscResource -Module @{ModuleName="PackageManagement"; ModuleVersion="1.4.8"} # assuming the changes are released in this version

    node localhost
    {
        PackageManagementSource PSGallery
        {
            Ensure = 'Present'
            Name = 'PSGallery'
            ProviderName = 'PowerShellGet'
            SourceLocation = 'https://www.powershellgallery.com/api/v2'
            InstallationPolicy = 'Trusted'
        }

        PackageManagement SF_PS_Http
        {
            Ensure = 'Present'
            Name = 'Microsoft.ServiceFabric.PowerShell.Http'
            MinimumVersion = '1.4.2-preview1'
            ProviderName = 'PowerShellGet'
            Source = 'PSGallery'
            AdditionalParameters = @{ AllowPrereleaseVersions = $true; InstallUpdate = $true; Scope = 'AllUsers'; AllowClobber = $true; SkipPublisherCheck = $true; Type = 'Module' }
            DependsOn = @('[PackageManagementSource]PSGallery')
        }
    }
}

@jberezanski jberezanski changed the title Fix/dsc additionalparameters switch MSFT_PackageManagement: Fix passing switch values in AdditionalParameters Feb 24, 2021
@jberezanski
Copy link
Author

It seems the AppVeyor jobs are trying to pull NuGet packages from a nonexistent feed (https://powershell.myget.org/F/powershell-core/api/v3/index.json).

…ndefault providers

Providers which are not included in PackageManagement, such as
DockerMsftProvider, are not loaded automatically. As a consequence,
their dynamic parameters are not returned by Get-Command. The fix
is to make sure the provider is loaded, which can be done if the
ProviderName is specified (always a good idea).

Also, in order to improve the fidelity of parameter type detection,
it is better to look only at parameters exposed by that provider.
Conveniently, for each provider, a separate ParameterSet is defined,
named after that provider.
1) fix cmdlet ParameterSet lookup to account for naming differences
2) add support for AdditionalParameters defined only for
   (Un)Install-Package and not for Get-Package (such as AcceptLicense
   for PowerShellGet)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant