Refactor and clean up based on the dependency management changes #194
Conversation
|
@SatishRanjan and @TylerLeonhardt Can you please take a look at this PR? |
src/Utility/Utils.cs
Outdated
| iss.ExecutionPolicy = Microsoft.PowerShell.ExecutionPolicy.Unrestricted; | ||
| } | ||
|
|
||
| s_initialSessionState = iss; |
There was a problem hiding this comment.
Is reusing same instance of InitialSessionState not going to cause issue especially when PowerShell instance pool size is greater than 1, say for example if an instance of PowerShell goes wrong then during Dispose associated session will be disposed as well which will cause other PowerShell instance not function correctly? Or even sharing same session state object across instance of PowerShell object will cause erroneous behavior?
There was a problem hiding this comment.
I'm glad you asked this question!
A cloned copy of the passed in initialsessionstate will be actually used for the Runspace creation, see https://github.com/PowerShell/PowerShell/blob/master/src/System.Management.Automation/engine/hostifaces/ConnectionBase.cs#L78
So it's safe to reuse the same initialsessionstate to create multiple Runspaces.
…re#194) Fix no runspace available Fix regression: create the first PowerShellManager in FunctionLoad, but delay the init Update comments Integrate all changes together Clear the outputbinding hashtable for the runspace after get the results Update tests and build scripts Create constant functions so it's more secure Alter the to-be-deployed PS function name to avoid conflicts with built-in functions Use PowerShell API instead of 'InvokeScript' as the former is way faster Bring back old code to clean global variables
Refactor and clean up the code base based on the dependency management changes.
initialsessionstatecreation and failure response inFunctionLoadprocessing_powershellPool.ReclaimUsedWorker(psManager);inProcessInvocationRequest.CRLFtoLFinUtils.cs.