Get-Help does not work in JEA sessions#2988
Get-Help does not work in JEA sessions#2988mirichmo merged 2 commits intoPowerShell:masterfrom chunqingchen:bugfix2
Conversation
|
@PaulHigin :) |
|
Can you please respond to me comment above? |
|
Please add a test |
|
@chunqingchen Please update this PR with tests per @SteveL-MSFT 's request |
|
@chunqingchen Please use a meaningful title and description for the PR. The current title and description is suitable for an issue but not for a PR.
|
There was a problem hiding this comment.
Please use $helpContent | Should Not Be $null
There was a problem hiding this comment.
Please make the title more informative for the test.
Sample - "Get-Help in JEA sessions".
There was a problem hiding this comment.
the test suite contains different bug fixes for JEA sessions. The information is contained in each test itself. thank you.
There was a problem hiding this comment.
I believe that we should not mention "bug fixes" in the title and it is better to make comments in It blocks with a link to the bug number below.
# Fix #1234567890There was a problem hiding this comment.
Please use correct case and replace -force with -Force.
|
@iSazonov your comment has been resolved. thank you |
There was a problem hiding this comment.
What is the user experience with this change? With this change does help still appear for cmdlets that are available in the JEA session? Please always include a description of the change along rationale for the change and any modification in experience.
With this change we now no longer throw a PathNotFound exception. How does this affect non-JEA sessions when the path cannot be resolved? Is it Ok to suppress the exception in this case?
There was a problem hiding this comment.
Strange but my previous comment no longer appears. Anyway my concern with this change is that previously an exception was thrown if the resolvedProviderPath is null, but now it continues. This feels like a breaking change since it now can return incomplete help for non-JEA sessions. I am not sure if that is a big deal but maybe it would be possible to detect JEA session before skipping the error.
|
Test LGTM. |
|
LGTM |
|
@daxian-dbw Hi, dongbo, can you help to merge? :) |
|
@chunqingchen It looks new commits were pushed after the sign-off from @iSazonov and @PaulHigin. Please work with @mirichmo to see if further review is needed. |
|
@mirichmo @PaulHigin The additional change I made is set the test case as pending because our current test harness is not supporting Register-PSSessionConfiguration cmdlet and needs further work around. however it won't blocking the product fix. Paul, would you please confirm if you are good with this? |
|
@PaulHigin Please take a look and provide an updated sign off since there were updates since the original sign off. |
There was a problem hiding this comment.
I just checked and it turns out that ExecutionContext.InitialSessionState property can be null. Please add a check for this.
PaulHigin
left a comment
There was a problem hiding this comment.
Please add check for _executionContext.InitialSessionState == null
|
@PaulHigin the comment has been resolved |
|
@chunqingchen This PR has been approved, but has merge conflicts. Please resolve them and push an update. I'll merge after that. |
Repro:
Expected behavior:
Help content is returned for the "Select-Object" cmdlet
Actual behavior: