SOAP support in all platforms

Summary of the new feature/enhancement

Currently, the only way to consume a SOAP API from PowerShell 6 or higher, is to render manually the XML envelopes and do a POST with Invoke-RestMethod. Before PowerShell 6, there was New-WebServiceProxy which managed to provide some of the WS* standards and worked quite well with most simple SOAP interfaces. When this was not enough, one could fall back to coding in C# leveraging the System.ServiceModel assembly which unfortunately is not ported to .NET Core and therefore it is not an alternative in PowerShell 6 or higher.

SOAP is not as dead as some people proclaim. Yes, it is not the current choice, but there are so many established API in SOAP, that makes it still alive. The one I've most recently encountered is the Amadeus which is used in the travel industry extensively and it doesn't seem to be going away soon. The travel industry, banking and insurance sector are known for keeping what works and for this reason the existing SOAP endpoints will not go away anytime soon. This makes PowerShell effectively a non-suitable scripting language and it shouldn't be.

SOAP support was already there and needs to become available again for all platforms.

Use cases I can think of are:

Use SOAP APIs from PowerShell on all platforms.
- Cheaper NX based VMs
- NX based containers support which are in general more lightweight than then windows server core counterparts.
Leverage a much-improved PowerShell 6 experience and performance when working with SOAP. SOAP tends to be generally heavy and I've already noticed how much faster the newer versions are compared to the previous ones
Integrate with SOAP using Azure Functions which currently supports only PowerShell 6. This would allow:
- A quick and dirty abstraction over REST
- Azure Logic apps would benefit as well
- Overall integration with other cognitive services and chatbots when SOAP is involved.
Windows Server Nano containers support.

Proposed technical implementation details

I think that this is not a PowerShell issue alone and support from the .NET team is required to port some of the missing APIs and assemblies and support the otherwise known WCF on other platforms.

Notice that on the roadmap announcement for .NET 5, many comments are about the missing support for WCF and there is quite a recognizable frustration.

Known repositories currently blocked from PowerShell 6

I've added some repositories that I've been in involved with over the last years when working with SOAP interfaces.

1ASOAP provides a toolkit for working with Amadeus (aka 1A) endpoints. The repository has three internal modules that are probably going to be split into 3 different repos. The SOAPProxy is the one that depends on New-WebServiceProxy to drive SOAP clients and this one blocks it from PowerShell 6. The remark is available here as well.
WcfPS was built around C# and the System.ServiceModel and System.IdentityModel assemblies. It generates in memory proxies but it can support even federated authentication (WSTrust 1.3) which is not available in PowerShell. The dependency on the System.ServiceModel effectively blocks it from PowerShell 6.
ISHRemote is an automation toolkit for a CMS over DITA by SDL known as Tridion Docs. It is built around C# and the System.ServiceModel and System.IdentityModel assemblies to leverage support for SOAP over federate authentications using WSTrust 1.3. The dependency on these assemblies blocks it PowerShell 6 and non-Windows based operating systems.

I don't know when or if .NET will support this, so an alternate would be if there was an Open Source library that is .NET Core compatible that could be used.

WRT a delivery vehicle, given that this is not a core scenario (anymore), I think making it availables as a module on PSGallery makes more sense. The trickier bit is getting the underlying .NET classes that PowerShell requires ported to Core. It might be helpful to open an issue in the .NET Core repository requesting this functionality.

It might be helpful to open an issue in the .NET Core repository requesting this functionality.

:-) And answer will

this is not a core scenario (anymore),

Although they could make a standalone package with the API.

Bruce Payette (@BrucePay)

Agree with Bruce Payette (@BrucePay), making it a standalone module makes sense regardless if we ship it with PowerShell package. Long term plan has been to have less cmdlets/modules ship with PowerShell and have them independently maintained, updated, and published on PSGallery.

In light of the news about PowerShell 7 trying to unify the fork and get us back on one version of PowerShell I came looking to see if New-WebServiceProxy was going to be addressed and found this issue.

I use New-WebService proxy to communicate with things like Adobe InDesign Server, Adobe Scene 7 Dynamic Media classic, ConnectShip Progistics (apis for shipping packages via Fedex, USPS, UPS, etc.), and in the past used this for managing Cisco Unified Communications Manager (and all the other on premise Cisco Collaboration tools).

Being able to quickly work with SOAP APIs is an important piece of the puzzule to enable System Administrators to automate a wide array systems they come in contact with using PowerShell.

Chris Magnuson (@ChrisMagnuson)

Chris Magnuson (@ChrisMagnuson) Thanks for your feedback! Based on MSFT team suggestion could you please clarify - do you ready to grab this in separate community project?

Now that .NET Team has announced a community project for WCF support, this may be viable. Haven't looked to see how complete it is. If there is interest by the community to talk this forward, I can create a public repo for you to use.

In the article they mention “NET Core WCF Client“.

Given that in powershell we are acting as a soap client could that be used?

Googling for that name didn’t come back with something that matched that exactly, maybe this is what they are referring to: https://github.com/dotnet/wcf

Chris Magnuson (@ChrisMagnuson)

Chris Magnuson (@ChrisMagnuson) I believe the right repo is https://github.com/CoreWCF/CoreWCF

Chris Magnuson (@ChrisMagnuson)

Chris Magnuson (@ChrisMagnuson) and Steve Lee (@SteveL-MSFT), I've done some more digging into this topic from the perspective of a couple of repositories I've in mind and mentioned on my original post.

The CoreWCF repo allows a soap client to function based on two requirements and their respected issues.

The interface and the data contracts are defined in code. This means a binary module. But, PowerShell as a scripting language, needs to ability to consume a SOAP endpoint dynamically like New-WebServiceProxy does.
Not all bindings are available, so complicated soap flows will not be supported. This limits the possibilities but I consider this a low impact issue. Most architect knew about the short commings of SOAP due to its complexity and have steered away from the most advanced bindings.

In the past, I've had already implemented an equivalent of the New-WebServiceProxy that could produce a more raw proxy but with much more support on the advanced bindings. I did this because I needed dynamic proxies that supported ws-trust authentication. This is WCFPS binary module and in short follows the following flow.

Create a wsdl importer
Extract the endpoint's interface and data contracts
Create a service endpoint based on a matching binding
Combine the interface and the service endpoint, to form a channel. The channel is the raw proxy. If you could wrap some code around it, then you could manage headers and add properties to mimic New-WebServiceProxy. Here is the example code.

$wsImporter=New-WcfWsdlImporter -Endpoint $svcEndpoint -HttpGet
$proxyType=$wsImporter | New-WcfProxyType
$endpoint=$wsImporter | New-WcfServiceEndpoint -Endpoint $svcEndpoint
$channel=New-WcfChannel -Endpoint $endpoint -ProxyType $proxyType

This is full WCF and hence it supports the most complicated bindings as they are described in the wsdl endpoint. Problem is that the necessary .net types are not implemented in the CoreWCF and I'm not sure if they are going to.

So, I considered a different approach. I've considered packaging dotnet-svcutil tool or its code into a module that behind the scenes would generate the code, compile it into memory and wrap it around an object. The problem is that I can't find the code for dotnet-svcutil and when I looked deeper I run into an answer stating "that this is not open source yet. ". I've also not been able to find the code for the New-WebServiceProxy to try and .NET standar-ize it and offer it a binary module.

I wonder is someone has some more insight about the source of dotnet-svcutil and New-WebServiceProxy

Alex Sarafian (@Sarafian)

Alex Sarafian (@Sarafian) See

PowerShell/src/Microsoft.PowerShell.Commands.Management/commands/management/WebServiceProxy.cs

Line 38 in bd6fdae

    
           [Cmdlet(VerbsCommon.New, "WebServiceProxy", DefaultParameterSetName = "NoCredentials", HelpUri = "https://go.microsoft.com/fwlink/?LinkID=135238")]

Please add this

This issue has not had any activity in 6 months, if this is a bug please try to reproduce on the latest version of PowerShell and reopen a new issue and reference this issue if this is still a blocker for you.

This issue has been marked as "No Activity" as there has been no activity for 6 months. It has been closed for housekeeping purposes.

Inspired by above comments (here and here), I created a hack-ish New-WebServiceProxy replacement which allowed my to use existing PS modules that relied on it (i.e. such as ReportingServicesTools). See my comment here as well as a gist I put together with various details and examples. Note that it would probably need to be heavily modified to be a drop-in replacement for any existing implementations due to how the WSDL code gen has changed.

gerneio

gerneio is the gist compatible with .net core? Problem with the code generated from a WSDL is that in some service descriptions, the code required for it to work hasn't been implemented in core I think.

When I had developed the WcfPS and the ISHRemote, we were using WSTrust 1.3 and segments from 1.4 which were not supported. In my opinion, this might be one of the biggest issues. Conditional compatibility with core depending on which parts of the WS* standards are used.
My apologis, it's been a while since I last worked with SOAP tech and I don't remember the terms very well.

The gist is using dotnet-svcutil, which the docs are saying is dotnet core.

All I can confirm for sure is that it worked as a drop-in replacement for the handful of cmdlets that I needed out of ReportingServicesTools. Other services might not be so straightforward. But yes, dotnet-svcutil is going to be the limiting factor since its the part that does the code gen, however it does look like that tool has matured quite a bit over ther years.

Fyi, i also had success running this in linux environments on PS Core.

The gist is using dotnet-svcutil, which the docs are saying is dotnet core.

Thanks. I wonder now about the coverage of the WS* standards. I did a quick check but didn't find much information.

Navigation Menu

Repository navigation

SOAP support in all platforms #9838

Summary of the new feature/enhancement

Proposed technical implementation details

Known repositories currently blocked from PowerShell 6

10 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

SOAP support in all platforms #9838

Description

Summary of the new feature/enhancement

Proposed technical implementation details

Known repositories currently blocked from PowerShell 6

Activity

SteveL-MSFT commented on Jun 6, 2019

BrucePay commented on Jun 6, 2019

iSazonov commented on Jun 6, 2019

SteveL-MSFT commented on Jun 6, 2019

ChrisMagnuson commented on Jun 19, 2019

iSazonov commented on Jun 20, 2019

SteveL-MSFT commented on Jun 20, 2019

ChrisMagnuson commented on Jun 20, 2019

SteveL-MSFT commented on Jun 20, 2019

Sarafian commented on Jun 21, 2019

iSazonov commented on Jun 21, 2019

10 remaining items

vazome commented on Nov 17, 2020

microsoft-github-policy-service commented on Nov 16, 2023

microsoft-github-policy-service commented on Nov 16, 2023

microsoft-github-policy-service commented on Nov 16, 2023

microsoft-github-policy-service commented on Nov 23, 2023

gerneio commented on Mar 24, 2025

Sarafian commented on Mar 25, 2025

wilsoncg commented on Mar 25, 2025

gerneio commented on Mar 25, 2025

Sarafian commented on Mar 25, 2025

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions