Open PRs should not be assigned to milestone, so they are not assigned to the wrong milestone after they are merged. For backport consideration, use a backport label.

I still have doubts that this is needed or that this is the right direction, as I don't see the analytics.

• Do we really have persistent requests for this?
• Who are these people?
• What do they really want to implement and when?

Is it worth taking any steps without understanding this? Perhaps they all want the same thing and we could join forces?

I may be wrong, but I feel and what first comes to mind is that (1) gRPC is starting to dominate on both Unix and Windows, (2) it's time for some PSRP extensions.
Sorry to repeat myself but this is happening because I don't see an analysis and arguments.

James Truher (@JamesWTruher) No new functionality was added so there is no need for new functional tests. Currently the only way I validate the new public APIs is via the example module I created (https://github.com/PaulHigin/SSHRemotingConnection). We could create new tests that takes a dependency on this module, but I feel it would not be that valuable for CI. I feel the best way to validate the new APIs is to have community members create their own custom connections and provide feedback.

GitHub

GitHub - PaulHigin/SSHRemotingConnection: Custom PowerShell custom remoting connection

Custom PowerShell custom remoting connection . Contribute to PaulHigin/SSHRemotingConnection development by creating an account on GitHub.

Ilya (@iSazonov) I agree that it is time to take a critical look at PowerShell's current remoting system. But this change is a very narrow scope to allow third parties to create custom connections with the current remoting system. Granted, not very many customers will take advantage of this, but it is still important for some scenarios. Specifically, this will allow third parties to create a custom Linux/Mac -> Windows (WinRM) solution, without having to modify internal PowerShell engine code. And this is something that many customers have asked for, and which we don't currently support.

James Truher (@JamesWTruher) No new functionality was added so there is no need for new functional tests. Currently the only way I validate the new public APIs is via the example module I created (https://github.com/PaulHigin/SSHRemotingConnection). We could create new tests that takes a dependency on this module, but I feel it would not be that valuable for CI. I feel the best way to validate the new APIs is to have community members create their own custom connections and provide feedback.

GitHub**GitHub - PaulHigin/SSHRemotingConnection: Custom PowerShell custom remoting connection**Custom PowerShell custom remoting connection . Contribute to PaulHigin/SSHRemotingConnection development by creating an account on GitHub.

one of the things that i've done are tests like:

it "the type 'new.public.newexcitingtype' should be public" {
("new.public.newexcitingtype" -as [type]).Name | Should -Be newexcitingtype
}

GitHub

GitHub - PaulHigin/SSHRemotingConnection: Custom PowerShell custom remoting connection

Custom PowerShell custom remoting connection . Contribute to PaulHigin/SSHRemotingConnection development by creating an account on GitHub.

I agree that it is time to take a critical look at PowerShell's current remoting system.

Paul Higinbotham (@PaulHigin) Thanks for clarify! I hope we open new discussion to collect ideas and prepare experiments.

James Truher (@JamesWTruher) That is an interesting idea but I don't see a lot of value in it. But I am thinking of creating a simpler named pipe custom module for testing. We already have support in our build for building test (module) binaries.

I'm hoping to test this out at some point in the next few days, excited to see it's here.

For testing it sounds like just replicating the NamedPipeConnectionInfo with your own custom pipe to ensure both the client and server can correctly transfer the data as expected would be a good test case.

This PR has 1429 quantified lines of changes. In general, a change size of upto 200 lines is ideal for the best PR experience!

Label      : Extra Large
Size       : +1103 -326
Percentile : 100%

Total files changed: 45

Change summary by file extension:
.yml : +2 -2
.psm1 : +33 -0
.cs : +640 -286
.resx : +4 -1
.ps1 : +343 -37
.config : +10 -0
.psd1 : +51 -0
.csproj : +20 -0

Was this comment helpful? 👍  :ok_hand:  :thumbsdown: (Email)
Customize PullRequestQuantifier for this repository.

Closing this PR after adding new one with clean changes.

#17011