Powershell: Port Web Cmdlets to CoreCLR

[jeffbi]

Port these cmdlets to CoreCLR:

• [x] ConvertTo-Html
• [x] Send-MailMessage
• [ ] New-WebServiceProxy

Two of these are mentioned in #2123

[thezim]

Is Send-MailMessage waiting on corefx?

[zippy1981]

New-WebServiceProxy would be great.

[jonathanmedd]

+1 on the missing New-WebServiceProxy

[SteveL-MSFT]

New-WebServiceProxy depends on System.Web.Services.dll which isn't part of corefx

[Glober777]

I have a lot of scripts depending on New-WebServiceProxy so can't easily migrate them over to PowerShell 6

[markekraus]

@Glober777 I looked into making something work for this. We can make something that works similar in PowerShell core, but it would not be backwards compatible in any way. The newer APIs for web services in .NET Framework and .NET Core behave differently than the deprecated System.Web.Services API. The reality is that New-WebServiceProxy will likely never be ported to PowerShell core, but, a new cmdlet may be created to work with SOAP and WSDL.

[jonathanmedd]

@markekraus That would be great if a new cmdlet became available at some point. My Brickset module is based around New-WebServiceProxy and I would like to update it to support PowerShell Core.

[markekraus]

@jonathanmedd For clarity, by "we" I mean Microsoft and the Community. SOAP is not something I personally have any need for, so this is very very low on my priority stack and not on on any of my roadmaps. So, I'm really wanting someone who actually needs the commands to lead the charge on this one. You game?

[jonathanmedd]

@markekraus totally understood, wasn't intentional to convey any expectation that you were personally going to deal with it ;-) Potentially I could be, would need to give it some thought. I guess I would need to learn C# first, although this might be an impetus that finally got me there.....

[iSazonov]

I guess I would need to learn C# first

First we need RFC for the new cmdlet. You could design the cmdlet if you have an expirience in web services. This will be a big step in solving this Issue.

[iSazonov]

Because System.Web.Services is deprecated we must consider New-WebServiceProxy cmdlet as deprecated too.
Anyone who is interested in the new web service cmdlet based on SOAP/WSDL should create new RFC.
Also anyone can use the New-WebServiceProxy cmdlet by means of Windows PowerShell Compatibility module.

So we have nothing to track here and I close the Issue.

[Sarafian]

@jonathanmedd For clarity, by "we" I mean Microsoft and the Community. SOAP is not something I personally have any need for, so this is very very low on my priority stack and not on any of my roadmaps. So, I'm really wanting someone who actually needs the commands to lead the charge on this one. You game?

I'm sorry but this statement is not very accurate. SOAP is also not my favourite but there are lots of companies with established products still using SOAP. The entire travelling industry is SOAP based. For example, [amadeus.com[(https://amadeus.com) API which is used by at airlines, trains, fairies etc is all SOAP based. There are almost 1/4 comments complaining about the lack of SOAP support in Introducing .NET 5.

Overall, with the current situation, we can't do any serious SOAP automation on PowerShell 6. With the roadmap for PowerShell 7 that was recently announced, it seems that this will be possible again but in reality, this will be only for Windows. However .NET Core 3 is presented, it is, in essence, a very fancy abstraction of the operating system and doesn't solve the shortcomings in the APIs of .NET Core and therefore PowerShell 7.

Unless I'm mistaken, Azure Functions over PowerShell supports only PowerShell 6.

I believe that the .net and PowerShell teams need to have a discussion about this topic. I really understand what the technology drivers are and I'm all against SOAP but the reality is that it exists on big proportions with no alternatives and that only 10years ago Microsoft was pushing very hard for WCF and developers followed. It is not well communicated why the System.ServiceModel assembly is not ported natively into the core API. Just dismissing SOAP doesn't sound like a good explanation to me, especially given our reality.

[quonic]

I believe that the .net and PowerShell teams need to have a discussion about this topic. I really understand what the technology drivers are and I'm all against SOAP but the reality is that it exists on big proportions with no alternatives and that only 10years ago Microsoft was pushing very hard for WCF and developers followed. It is not well communicated why the System.ServiceModel assembly is not ported natively into the core API. Just dismissing SOAP doesn't sound like a good explanation to me, especially given our reality.

I've switched to Python because I can't talk to SOAP API's with Powershell on Linux. I love Powershell, but I can't use it at work for SOAP related automation's. I'm not a good enough programmer to replicate what New-WebServiceProxy does. I wish I was, then I would do it myself.

[iSazonov]

.Net Core 3.0 will have WCF client API and MSFT PowerShell team will seems return back some code back for better compatibility with Windows PowerShell. I am not sure about System.Web.Services and New-WebServiceProxy. Perhaps it could be in compatibility module.

/cc @SteveL-MSFT

[Sarafian]

As long as it can execute on all operating systems it should be fine. Unfortunately, the messaging, e.g. desktop ui apps on .net core 3, is so misleading with regards to actual API support from .net core

[Sarafian]

@quonic the problem with soap is that it is build upon many different WS* standards and that creates a big gap between understanding, knowing and using. WCF was a massive effort by Microsoft to abstract it away and though successful it was too late. Those WS* defined many aspects of https that we take for granted when using rest.

I just want to say that the effort requires so much knowledge of the standards that it would had been difficult to implement by one person. This why those assemblies were so useful. I suspect that the crypto elements within the system.servicemodel assembly were the tricky part and a simple code port was not feasible. Still it is a pity given the investment and faith into WCF.

[SteveL-MSFT]

For those interested in SOAP support, please open a new issue to discuss.

[Sarafian]

For those interested in SOAP support, please open a new issue to discuss.

On PowerShell or .NET core? What is you preference?

[iSazonov]

@Sarafian In the PowerShell repo. Please add motivation and use-cases.

[Sarafian]

@Sarafian In the PowerShell repo. Please add motivation and use-cases.

GH-9838