Skip to content

Use prefixed QNames in XPath expressions used by all implementations of ICmdletProviderSupportsHelp interface#2089

Merged
vors merged 3 commits intoPowerShell:masterfrom
0xfeeddeadbeef:master
Sep 13, 2016
Merged

Use prefixed QNames in XPath expressions used by all implementations of ICmdletProviderSupportsHelp interface#2089
vors merged 3 commits intoPowerShell:masterfrom
0xfeeddeadbeef:master

Conversation

@0xfeeddeadbeef
Copy link
Copy Markdown
Contributor

@0xfeeddeadbeef 0xfeeddeadbeef commented Aug 26, 2016

Fixes #2088 Provider-specific help cannot be loaded from MAML XML files because of incorrect XPath query.

Also includes these bugfixes:

  • WSManConfigProvider.GetHelpMaml: Tried to load XML from
    MemoryStream that was created from file name string. Use XmlReader
    instead.
  • WSManConfigProvider.GetHelpMaml: Use Path.Combine instead of
    platform-specific directory separator character.
  • WSManConfigProvider.GetHelpMaml: CmdletHelpPath MAML XML element
    attribute ID must be lowercase.

I have no idea how to test this using Pester, -- affected classes seem to be difficult (or impossible?) to isolate in tests. I would appreciate any ideas.

@msftclas
Copy link
Copy Markdown

Hi @0xfeeddeadbeef, I'm your friendly neighborhood Microsoft Pull Request Bot (You can call me MSBOT). Thanks for your contribution!

In order for us to evaluate and accept your PR, we ask that you sign a contribution license agreement. It's all electronic and will take just minutes. I promise there's no faxing. https://cla.microsoft.com.

TTYL, MSBOT;

@msftclas
Copy link
Copy Markdown

@0xfeeddeadbeef, Thanks for signing the contribution license agreement so quickly! Actual humans will now validate the agreement and then evaluate the PR.

Thanks, MSBOT;

@adityapatwardhan
Copy link
Copy Markdown
Member

The changes looks good. Can you add tests for this under: https://github.com/PowerShell/PowerShell/blob/master/test/powershell/engine/HelpSystem.Tests.ps1

In the test you could use Select-Xml to get the provider specific help for Get-Item like:

$Namespace = @{command = "http://schemas.microsoft.com/maml/dev/command/2004/10"; maml = "http://schemas.microsoft.com/maml/2004/10"; dev = "http://schemas.microsoft.com/maml/dev/2004/10"; msh = "http://msh"}

$Path = "$PSHome\en-US\System.Management.Automation.dll-help.xml"

$xPath = "/msh:helpItems/msh:providerHelp/msh:CmdletHelpPaths/msh:CmdletHelpPath[@id='FileSystem']/command:command[command:details/command:verb='Get' and command:details/command:noun='Item']"

$op = Select-Xml -Path 'C:\Windows\System32\WindowsPowerShell\v1.0\en-US\System.Management.Automation.dll-help.xml' -XPath $xPath  -Namespace $Namespace | Select-Object -ExpandProperty Node

$op.description.para 

$op.description.para should match the description returned from the

(get-help get-item).description

@TravisEz13
Copy link
Copy Markdown
Member

@0xfeeddeadbeef
Copy link
Copy Markdown
Contributor Author

0xfeeddeadbeef commented Aug 31, 2016

I've added some basic tests, ran CI build multiple times and results are not good: works badge

When invoked at AppVeyor, Get-Help -Name "$verb-$noun" -Path $path cmdlet returns "bare" help, i.e. only command syntax, - no description, no synopsis, no other details. It even fails to locate the default help. I was unable to find the root cause of this.

This happens at AppVeyor:

Get-Help -Name "New-Item" -Path 'Cert:\' | Select-Object -ExpandProperty Synopsis

# output
New-Item [-Path] <string[]> [-ItemType <string>] [-Value <Object>] [-Force] [-Credential <pscredential>] [-WhatIf] [-Confirm] [<CommonParameters>]

New-Item [[-Path] <string[]>] -Name <string> [-ItemType <string>] [-Value <Object>] [-Force] [-Credential <pscredential>] [-WhatIf] [-Confirm] [<CommonParameters>]

This output, obviously, will not match the text from help.xml.

When run locally, using fresh & clean build, same cmdlet is able to load text from help.xml file:

Get-Help -Name "New-Item" -Path 'Cert:\' | Select-Object -ExpandProperty Synopsis

# output
Creates new certificate stores in the LocalMachine store location.

As for Linux (Travis CI), these tests would fail, because:

  1. Fresh build output does not contain help.xml files, Pester test must run Update-Help to retrieve them; but Update-Help is not yet supported on Linux (It is using Windows Cabinet API internally). Without Update-Help, there will be no help.xml files to load provider-specific help from.
  2. Cert:\ and WSMan:\ providers are not yet supported on non-Windows platforms (Correct me if I'm wrong).

I've disabled these tests when build is not running on Windows.

Looks like I am stuck here.

@adityapatwardhan @TravisEz13 Any ideas?

@TravisEz13
Copy link
Copy Markdown
Member

@0xfeeddeadbeef , to build the same way and run the same tests which are failing, please run the following on windows from the root of the PowerShell repo:

Import-Module .\tools\appveyor.psm1
Invoke-AppVeyorFull

You may need to rebase the latest changes as this command was only added recently.
Warning: this will rerun start-psbootstrap

@0xfeeddeadbeef
Copy link
Copy Markdown
Contributor Author

@TravisEz13 Thank you. That's really useful tip. I was able to attach a debugger and I think I'm onto something: when running with generated native images, ProviderBase.ProviderInfo.HelpFile property returns something like this: OriginalAssemblyName.ni.dll-Help.xml - notice the ni in the name. Looks like this bug is burrowed even deeper. I'll try to figure it out...

@TravisEz13
Copy link
Copy Markdown
Member

@0xfeeddeadbeef No Problem, it's a very recent change. I haven't even documented it yet.

@adityapatwardhan
Copy link
Copy Markdown
Member

@0xfeeddeadbeef It seems all the tests are passing. Are more changes expected for this issue?

@0xfeeddeadbeef
Copy link
Copy Markdown
Contributor Author

@adityapatwardhan That's all. No more changes.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Instead of skipping here. Please skip in "It" using -skip (-not $IsWindows) {... }. This makes sure that we log that these tests are skipped.

…of ICmdletProviderSupportsHelp interface

Also includes these bugfixes:
  - WSManConfigProvider.GetHelpMaml: Tried to load XML from
    MemoryStream that was created from file name string. Use XmlReader
    instead.
  - WSManConfigProvider.GetHelpMaml: Use Path.Combine instead of
    platform-specific directory separator character.
  - WSManConfigProvider.GetHelpMaml: CmdletHelpPath MAML XML element
    attribute `ID` name casing seems inconsistent with other help.xml
    files. XPath 1.0 does not support case-insensitive expressions,
    use both `id` and `ID` in query.
  - Add Pester test to verify that Get-Help shows provider-specific help.

Fixes #2088
@adityapatwardhan
Copy link
Copy Markdown
Member

adityapatwardhan commented Sep 13, 2016

:shipit: Looks good to me.

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.

Provider-specific help cannot be loaded from MAML XML files because of incorrect XPath query

6 participants