Wcf: SOAP Headers not working in NetCore

Created on 14 Jan 2016  路  15Comments  路  Source: dotnet/wcf

Jeff reported the issue at a MSDN blog,

As far as I can tell this does not handle SOAP headers. Can you confirm that they are not yet supported under .NET Core? If they are not, are there any potential workarounds that do not involve changing the server? Thanks!

After doing a bit of digging, it looks like the part that is missing (or at least the first part) is the implementation of System.ServiceModel.Dispatcher.OperationFormatter.XmlElementMessageHeader.OnWriteHeaderAttributes. Presumably because it used XmlNodeReader, which has not been implemented either. I can't find much of anything on why that isn't implemented, but my first guess would be that it's because not much of anything seems to use it.

Most helpful comment

@maslakov Please, can you show how to do this workaround that you mentioned?

@linflux OK so I was able to work around this using a message inspector (which I believe is the same workaround that @maslakov refers to) and it seems to work well for both .NET Core and UWP. I decided to whip up a blog post about it:

Calling Salesforce SOAP APIs from a .NET Core or UWP App

All 15 comments

Here is a simple project to reproduce the issue: SoapHeaderTest.zip

Unhandled Exception: System.PlatformNotSupportedException: Operation is not supported on this platform.
   at System.ServiceModel.Dispatcher.OperationFormatter.XmlElementMessageHeader.OnWriteHeaderAttributes(XmlDictionaryWriter writer, MessageVersion messageVersion)
   at System.ServiceModel.Channels.Message.WriteMessagePreamble(XmlDictionaryWriter writer)
   at System.ServiceModel.Channels.Message.OnWriteMessage(XmlDictionaryWriter writer)
   at System.ServiceModel.Channels.BufferedMessageWriter.WriteMessage(Message message, BufferManager bufferManager, Int32 initialOffset, Int32 maxSizeQuota)
   at System.ServiceModel.Channels.TextMessageEncoderFactory.TextMessageEncoder.WriteMessageAsync(Message message, Int32 maxMessageSize, BufferManager bufferManager, Int32 messageOffset)
   at System.ServiceModel.Channels.TextMessageEncoderFactory.TextMessageEncoder.WriteMessage(Message message, Int32 maxMessageSize, BufferManager bufferManager, Int32 messageOffset)
   at System.ServiceModel.Channels.BufferedMessageContent.EnsureMessageEncoded()
   at System.ServiceModel.Channels.BufferedMessageContent.TryComputeLength(Int64& length)
   at System.Net.Http.HttpContent.GetComputedOrBufferLength()
   at System.Net.Http.Headers.HttpContentHeaders.get_ContentLength()
   at System.Net.Http.WinHttpHandler.IsChunkedModeForSend(HttpRequestMessage requestMessage)
   at System.Net.Http.WinHttpHandler.<StartRequest>d__101.MoveNext()

Assigned the issue to myself to investigate. The test I wrote for #676 is failing because of this issue.

The desktop implementation of _XmlElementMessageHeader.OnWriteHeaderAttributes()_ uses _XmlNodeReader_ type, which is not available in NetCore.

This requires new APIs that will not be available for 1.1.

As a workaround until it is fixed, headers still can be added manually via IClientMessageInspector.
Just had to do that in my project

I also encountered the same problem, when to solve this issue?

Looks like XmlNodeReader is now added in corefx. We will see if this is something we can do in 1.2 release timeframe. This, however, will bump up the version of.NET Standard that WCF supports from 1.3 to 2.0.

@maslakov Please, can you show how to do this workaround that you mentioned?

Just a note to illustrate how impactful this issue is: it makes it effectively impossible to integrate with any of the various Salesforce SOAP APIs (including data, metadata, tooling, etc) from .NET Core and UWP (the Add Service Reference gesture in a UWP project evidently suffers from the same limitation). These APIs all rely heavily on SOAP headers for supplying basic things such as authentication tokens.

@maslakov Please, can you show how to do this workaround that you mentioned?

@linflux OK so I was able to work around this using a message inspector (which I believe is the same workaround that @maslakov refers to) and it seems to work well for both .NET Core and UWP. I decided to whip up a blog post about it:

Calling Salesforce SOAP APIs from a .NET Core or UWP App

@shmao, what will be the next step to fix this issue? There are a few more reports of this issue now.

cc: @hongdai

The next step for us is to make NetCore support serializing types with Soap attributes. This is tracked by https://github.com/dotnet/corefx/issues/10579 and https://github.com/dotnet/corefx/issues/12799. Since we use CodeDom for serializing Soap types on desktop full framework and CodeDom is not available on NetCore, we would need new implementation for this. The current plan is to use reflection based serialization to serialize Soap types.

Upon the completion of the above step, we probably would be able to make changes in WCF to handle SOAP headers.

My comment above was wrong. I mixed up the bug with other issues. I'm working on a fix for this.

This post shows how the technique @maslakov describes...

http://www.ideliverable.com/blog/calling-salesforce-soap-apis-from-a-net-core-or-uwp-app

Hi,

Is this issue resolved now? I can see in my .net core client that it is not able to fetch SOAP header from response. I am using connected service proxy class. It is always dropping soap headers in de-serialization.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

mconnew picture mconnew  路  5Comments

Petermarcu picture Petermarcu  路  4Comments

mconnew picture mconnew  路  6Comments

apdirexyon picture apdirexyon  路  5Comments

wstaelens picture wstaelens  路  3Comments