You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
Mark Kraus (@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.
Jonathan Medd (@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?
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.
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.
Jonathan Medd (@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.
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.
.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.
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
Spyingwind (@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.
Activity
thezim commentedon Sep 13, 2016
Is Send-MailMessage waiting on corefx?
zippy1981 commentedon Oct 5, 2016
New-WebServiceProxy would be great.
jonathanmedd commentedon Mar 4, 2017
+1 on the missing New-WebServiceProxy
SteveL-MSFT commentedon Aug 14, 2017
New-WebServiceProxydepends on System.Web.Services.dll which isn't part of corefxGlober777 commentedon May 14, 2018
I have a lot of scripts depending on New-WebServiceProxy so can't easily migrate them over to PowerShell 6
markekraus commentedon May 14, 2018
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.ServicesAPI. The reality is thatNew-WebServiceProxywill likely never be ported to PowerShell core, but, a new cmdlet may be created to work with SOAP and WSDL.jonathanmedd commentedon May 14, 2018
Mark Kraus (@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 commentedon May 14, 2018
Jonathan Medd (@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?
1 remaining item
iSazonov commentedon May 14, 2018
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 commentedon Aug 29, 2018
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 commentedon May 31, 2019
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.ServiceModelassembly 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 commentedon May 31, 2019
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 commentedon May 31, 2019
.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 Steve Lee (@SteveL-MSFT)
Sarafian commentedon Jun 2, 2019
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 commentedon Jun 2, 2019
Spyingwind (@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 commentedon Jun 5, 2019
For those interested in SOAP support, please open a new issue to discuss.
Sarafian commentedon Jun 5, 2019
On PowerShell or .NET core? What is you preference?
iSazonov commentedon Jun 6, 2019
Alex Sarafian (@Sarafian) In the PowerShell repo. Please add motivation and use-cases.
Sarafian commentedon Jun 6, 2019
GH-9838