This can be simplified to:

get => base.WorkingDirectory;
set => base.WorkingDirectory = value;

No strong opinion here but: I am tempted to leave this as it is and the reason for that is the rest of the file that I am touching follows this pattern for the get\sets source

Generally speaking from what I've seen, when most contributors add new code, they do so using the current practices rather than match existing syntax. This keeps us forward moving. Eventually PRs come in to advance old syntax to catch up to newer syntax.

Sure, I will fix it in the next iteration

Here can be a security issue.
Should we check that is really directory and it is impossible inject bad code?

/cc @PaulHigin @TravisEz13

This is a really good point.

I do check the directory to see if its valid in StartJob.cs here and throw if its not.

The reason I did not make the check in the PSRemotingCmdlet is that I wanted to enable the scenario where this parameter is expanded to other cmdlets that inherit from PSRemotingCmdlet.

That being said I could be really defensive and add a command that checks that the string provided by the user is indeed a valid path.

Adding a command should be considered like parameterized SQL.

Impossible is the wrong bar here.

@iSazonov I'm not sure what the problem is with setting the working directory with a string parameter (this is not a scriptblock).

Something about this doesn't feel right. Starting with the test:

Start-Job -ScriptBlock { Join-Path $pwd "" } -WorkingDirectory $tempPath 

I think this code does the equivalent of:

Set-Location $tempPath | Join-Path $pwd ""

Instead of:

Set-Location $tempPath
Join-Path $pwd ""

I think you need to call PSCommand.AddStatement on this command you're adding.

If I understand correctly what you are saying is that the object Pipeline represents only the powershell pipeline and if I want to create a sequence of commands I would need to add a statement to the powershell instance instead of adding a command to the pipeline.

This means that the correct approach is to have something like this:

_powershellV3 = System.Management.Automation.PowerShell.Create();
if (WorkingDirectory != null)
{
    _powershellV3.AddStatement().
             AddCommand("Microsoft.PowerShell.Management\\Set-Location").
             AddParameter("LiteralPath", WorkingDirectory);
}

I would assume that this statement should be added for both when the server is ps2 and ps5+.

(P.S. thanks for the comment it helped me understand the code way better)

I think what @lzybkr is trying to draw your attention to is what happens if WorkingDirectory != null on line 1852 of PSRemotingCmdlet.cs is true. In that case, you add the Set-Location command to the empty set of pipeline commands (the collection that was previously cleared on line 1850), but then logic continues beyond your if-statement and commands are added as additional commands in that same pipeline that Set-Location is in on lines 1859-1862. If you insert pipeline.Commands.AddStatement(); before line 1857, you'll properly terminate the statement that invokes Set-Location, allowing the commands that are being invoked to be property added as a separate commands following that statement.

The PowerShell api was originally designed for a single pipeline, but you could do more with that api if you used AddScript.

Some secure endpoints disallow script (no language mode), so the PowerShell instance must be expressible as commands. At some point in the past, this also meant a "Pipeline" was exactly that, it was a single pipeline.

I think in V3 we added support for multiple distinct statements via the AddStatement api. You can think of AddCommand as adding a | between every statement unless AddStatement was called, then we'd add a ; instead. I also think that means the correct code is more like:

    _powershellV3.
             AddCommand("Microsoft.PowerShell.Management\\Set-Location").
             AddParameter("LiteralPath", WorkingDirectory).
             AddStatement();

I do see that the test passed though, and that surprised me. I'd do some more testing to verify my assumptions above.

I don't recall specifics about going between the PowerShell api and the Pipeline api, and to be honest, I find the original code here (before the PR) a little confusing, so I'm reluctant to say that AddStatement is definitely needed.

I should also mention the need for compatibility testing if AddStatement is needed. I recall a bug where the conversion from a script block to a PowerShell instance could not use AddStatement because of a bug in the server side code. If I'm remembering this correctly, the bug was fixed in V5, so it would probably be worth testing across different server versions.

This should probably the module, like:

var command = new Command("Microsoft.PowerShell.Management\\Set-Location");