Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.
Sign upHelp System as a standalone PowerShell Module #102
Conversation
msftclas
added
the
cla-not-required
label
Jul 27, 2017
| Help system is used predominantly in interactive sessions and hence not required for automation scenarios. | ||
| Since, it is part of System.Management.Automation.dll it is always loaded with PowerShell. | ||
| Help system is sizeable piece of code, which increases the runtime footprint of the process. | ||
| This RFC proposes to make the help system a PowerShell module, so it is loaded only when used. |
This comment has been minimized.
This comment has been minimized.
iSazonov
Aug 3, 2017
Contributor
We could add HelpSystem abstract class to allow customers to implement help system themselves.
This comment has been minimized.
This comment has been minimized.
adityapatwardhan
Aug 3, 2017
Member
I intend to implement a plugin model. Since that is implementation detail, I did not include it in here.
This comment has been minimized.
This comment has been minimized.
SteveL-MSFT
Aug 4, 2017
Member
If you have thoughts on public api's, I think it's worth including here or note that it'll be in a separate RFC
This comment has been minimized.
This comment has been minimized.
iSazonov
Aug 4, 2017
Contributor
It make sense to write this explicitly that users can implement custom Help system module based on new public API..
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
iSazonov
Jan 25, 2018
Contributor
If the intention is to make a plugin model will this root code in the engine? I would see all help root code in a separate module, and plugins in other modules.
| | UpdatableHelpCommandBase | Used by UpdateHelpCommand, breaking change impact is medium. | ||
| | UpdateHelpCommand | Sealed class, breaking change impact is low. | ||
|
|
||
| [CLR Type Forwarding](https://docs.microsoft.com/en-us/dotnet/framework/app-domains/type-forwarding-in-the-common-language-runtime) will be considered to lessen the impact of the breaking change. |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
adityapatwardhan
Aug 3, 2017
Member
I will mostly likely be used. I still need to investigate the impact if the forwarded type is not found, for example Microsoft.PowerShell.HelpSystem module is removed.
This comment has been minimized.
This comment has been minimized.
adityapatwardhan
Sep 19, 2017
Member
Actually, this might not be feasible as type forwarding only works if the namespace is same.
This comment has been minimized.
This comment has been minimized.
iSazonov
Sep 20, 2017
Contributor
We could place mandatory types in mandatory assembly (maybe leave in SMA) and any extentions put in optional assemblies (and maybe another namespace).
HelpSystem is based on help providers so we could consider to make the help providers as optional and loadable.
This comment has been minimized.
This comment has been minimized.
|
This is great, love it |
SteveL-MSFT
referenced this pull request
Sep 5, 2017
Open
HelpSystem should consume markdown natively #3954
msftgits
removed
the
cla-not-required
label
Sep 26, 2017
adityapatwardhan
added some commits
Jul 27, 2017
adityapatwardhan
force-pushed the
adityapatwardhan:HelpSystemModule
branch
from
7da9286
to
1a682e4
Apr 2, 2018
joeyaiello
added
the
Review - Committee
label
Apr 2, 2018
This comment has been minimized.
This comment has been minimized.
|
@PowerShell/powershell-committee has decided to take this into the experimental folder so that we can begin prototyping/implementing without blocking on a vote. I personally want to follow up on the CLR type forwarding aspect of this scenario, so @adityapatwardhan and company are going to be doing some investigation there as part of the prototyping effort. |
|
|
||
| [CLR Type Forwarding](https://docs.microsoft.com/en-us/dotnet/framework/app-domains/type-forwarding-in-the-common-language-runtime) will be considered to lessen the impact of the breaking change. | ||
|
|
||
| The interactive user experience would not change as command discovery will find the ```Get-Help```, ```Save-Help``` and ```Update-Help``` commands from the 'Microsoft.PowerShell.HelpSystem' module instead from 'Microsoft.PowerShell.Core' module (System.Management.Automation.dll). |
This comment has been minimized.
This comment has been minimized.
HemantMahawar
Jul 25, 2018
Member
We need to make sure that scripting scenarios with fully qualified module names (Microsoft.PowerShell.Core\Get-Help) is NOT broken. PowerShell engine should support both - old module qualified names and the new module qualified names.
| Plan to implement: Yes | ||
| --- | ||
|
|
||
| # Help System as a standalone PowerShell Module |
adityapatwardhan commentedJul 27, 2017
•
edited by SteveL-MSFT
This RFC proposes making HelpSystem as a standalone PowerShell module and remove it from System.Management.Automation.dll.
This change is