This is blocked by several issues (that I have found so far):

LoadUserProfile doesn't work on Linux, and PoweShell executable does not have ".exe" suffix on Linux:

--- a/monad/src/engine/hostifaces/PowerShellProcessInstance.cs
+++ b/monad/src/engine/hostifaces/PowerShellProcessInstance.cs
@@ -37,8 +37,9 @@ namespace System.Management.Automation.Runspaces
///

     static PowerShellProcessInstance()
     {

       string executable = Platform.IsWindows() ? "powershell.exe" : "powershell";^M
     PSExePath = Path.Combine(Utils.GetApplicationBase(Utils.DefaultPowerShellShellID),

                       "powershell.exe");

```
                       executable);^M
 }

 /// <summary>
```
@@ -112,9 +113,13 @@ namespace System.Management.Automation.Runspaces
RedirectStandardOutput = true,
RedirectStandardError = true,
CreateNoWindow = true,

                           LoadUserProfile = true,
                     };

```
       if (Platform.IsWindows())^M
```
```
       {^M
```

           _startInfo.LoadUserProfile = true;^M

```
       }^M
```
+^M

PowerShell is invoked with -s and -EncodedCommand, neither of which is supported by PSL. The "-s" option is undocumented. From PSCore Slack group:

andrew [4:18 PM] 
ServerMode aka 'OutOfProcessServer'
ps_dev\admin\monad\src\host\msh\CommandLineParameterParser.cs(393): else if (MatchSwitch(switchKey, "servermode", "s"))

andrew [4:25 PM] 
basically this option runs
System.Management.Automation.Remoting.Server.OutOfProcessMediator.Run(cpp.InitialCommand);
in ps_dev\admin\monad\src\host\msh\ConsoleHost.cs

paulhi [7:28 AM] 
The -s option is to run PowerShell in server mode for out of process (background) jobs. There are two other server modes: socketservermode (-so), namedpipeservermode (-nam) that are used for Hyper-V/Container remoting. These modes are only used internally and so the switches are undocumented.

To implement "-s" option mentioned in Import issues from VSO #2 above, you will hit a dependency on native WindowsIdentify. This is one possible workaround:

--- a/monad/src/engine/remoting/server/OutOfProcServerMediator.cs
+++ b/monad/src/engine/remoting/server/OutOfProcServerMediator.cs
@@ -298,8 +298,20 @@ namespace System.Management.Automation.Remoting.Server
```
 protected OutOfProcessServerSessionTransportManager CreateSessionTransportManager(string configurationName)
 {
```

       WindowsIdentity currentIdentity = WindowsIdentity.GetCurrent();

       PSPrincipal userPrincipal = new PSPrincipal(new PSIdentity("", true, currentIdentity.Name, null),

```
       string name;^M
```

       WindowsIdentity currentIdentity;^M

```
       if (Platform.IsWindows())^M
```
```
       {^M
```

           currentIdentity = WindowsIdentity.GetCurrent();^M

           name = currentIdentity.Name;^M

```
       }^M
```
```
       else^M
```
```
       {^M
```
```
           currentIdentity = null;^M
```

           name = Platform.NonWindowsGetUserName();^M

```
       }^M
```
+^M

       PSPrincipal userPrincipal = new PSPrincipal(new PSIdentity("", true, name, null),^M

Another native WIndows problem to be hit is related to CryptoLibrary. In monad/src/utils/CryptoUtils.cs, the constructor PSRSACryptoServiceProvider pinvokes Windows's CrytoAcquireContext(). The ideal way around this is to re-write the PSCrytoNativeUtils class with System.Security.Crytography.AesCryptoServiceProvider.

Investigate why Start-Job fails #452

Description

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions