Wcf: Add Mtom support in WCF runtime

[chris5287]

I am getting the following error when using the Visual Studio WCF Connected Service extension for Visual Studio 2017:

Scaffolding Code ...
Error:Warning: The following Policy Assertions were not Imported:   XPath://wsdl:definitions[@targetNamespace='http://imaging.oracle/']/wsdl:binding[@name='DocumentContentServicePortBinding']
  Assertions:
    <ns1:OptimizedMimeSerialization xmlns:ns1='http://schemas.xmlsoap.org/ws/2004/09/policy/optimizedmimeserialization'>..</ns1:OptimizedMimeSerialization>
Warning: Unsupported binding element type: 'System.ServiceModel.Channels.UnrecognizedAssertionsBindingElement'.
Warning: Unsupported message encoding element type: 'System.ServiceModel.Channels.MtomMessageEncodingBindingElement'. It must be one of the following types: 'System.ServiceModel.Channels.BinaryMessageEncodingBindingElement', 'System.ServiceModel.Channels.TextMessageEncodingBindingElement.'
Warning: Endpoint 'DocumentContentServicePort' at address 'http://localhost/imaging/ws/DocumentContentService' contains one or more bindings not compatible with .Net Core apps, skipping...
Error: No endpoints compatible with .Net Core apps were found.
Failed to generate service reference.

The WSDL/XSD file causing the issue:
DocumentContentService.xsd.txt
DocumentContentService.wsdl.txt

dotnet --info

.NET Command Line Tools (1.0.0)

Product Information:
 Version:            1.0.0
 Commit SHA-1 hash:  e53429feb4

Runtime Environment:
 OS Name:     Windows
 OS Version:  6.1.7601
 OS Platform: Windows
 RID:         win7-x64
 Base Path:   C:\Program Files\dotnet\sdk\1.0.0

[hongdai]

Hi Chris, this is because WCF runtime currently does not support Mtom. Potential workaround is try to disable Mtom on the service side if you have access to the service.

If your scenario needs Mtom support, please go ahead open a issue for WCF runtime to consider adding the support.

Thanks,
Hong

[chris5287]

Hi Hong, I'm afraid I do not have control over the server side :(

Where do I need to raise the issue to add Mtom support, or does this issue already cover it?

[hongdai]

I think you can rename this issue to add Mtom support in WCF runtime. We share the same git Repro.

[eserozvataf]

Same issue for me.

Warning: Unsupported binding element type: 'System.ServiceModel.Channels.UnrecognizedAssertionsBindingElement'.
Warning: Unsupported message encoding element type: 'System.ServiceModel.Channels.MtomMessageEncodingBindingElement'. It must be one of the following types: 'System.ServiceModel.Channels.BinaryMessageEncodingBindingElement', 'System.ServiceModel.Channels.TextMessageEncodingBindingElement.'
Warning: Endpoint 'ZPM_ITS_ORDER_soap12' at address 'http://tpsappr1.customer.sap.local:8000/sap/bc/srt/rfc/sap/zpm_its_order_detail_ws/400/zpm_its_order/zpm_its_order' contains one or more bindings not compatible with .Net Core apps, skipping...
Warning: Endpoint 'ZPM_ITS_ORDER' at address 'http://tpsappr1.customer.sap.local:8000/sap/bc/srt/rfc/sap/zpm_its_order_detail_ws/400/zpm_its_order/zpm_its_order' contains one or more bindings not compatible with .Net Core apps, skipping...
Error: No endpoints compatible with .Net Core apps were found.

Failed to generate service reference.

[OkuraSt]

same here @eserozvataf

Do you have any workarounds for consuming this type of SAP WS in net core?

Warning: Endpoint 'ZBWS_MAT_STOCKALMACEN' at address 'http://lcs03..local:8000/sap/bc/srt/rfc/sap/zws_mat_stockalmacen/200/zws_mat_stockalmacen/zbws_mat_stockalmacen' contains one or more bindings not compatible with .Net Core apps, skipping...
Error: No endpoints compatible with .Net Core apps were found.

Failed to generate service reference.

[suadev]

Same here :(

[felipecaputo]

Hello folks! Is there any chance to get this implemented?

[zhenlan]

Not in a plan at this point. Please upvote if this is important. It will be helpful for future planning.

[felipecaputo]

I've tried to consume a java SOAP without mtom enabled, and it accepted my request, but the response came with xop/xml.

The content type multipart/related; type=\"application/xop+xml\" ... start-info=\"text/xml\" of the response message does not match the content type of the binding (text/xml; charset=utf-8). If using a custom encoder, be sure that the IsContentTypeSupported method is implemented properly

There is any way I can add a custom decoder to receive this message, while it isn't supported yet?

[Kantuz001]

Same problem(

[napalm684]

Has anyone figured out a work around? I can get the action to occur via the SOAP call but the response is what is failing. Even if I could get the string of the response (which is in the exception message) I could parse what I need out of it as a short term fix.

[felipecaputo]

not yet :(

[dnbr2002]

We could really use some support for this and were hoping with dotnet core 2.0 it might get included. Any chance it's being added in a future release?

[rezvanf]

I have the same problem

I've tried to consume a java SOAP without mtom enabled, and it accepted my request, but the response came with xop/xml.

What i don't understand is at the supported features for .net core 1.0

https://github.com/dotnet/wcf/blob/master/release-notes/SupportedFeatures-v1.0.0.md

It shows message encoding for both text and binary supported.

So how do we do this please if we are consuming WCF services in our .net core apps and need message encoding of WSEncoding.Mtom

[mconnew]

I thought I would give some background on why this isn't a trivial task. This isn't a case of simply copying the code over. On the full framework we use HttpWebRequest for sending an HTTP request. We get the request stream from HttpWebRequest and then write the request message to it.

In .Net Core, we don't have HttpWebRequest available and so need to use HttpClient instead. This has a completely different model for sending a request, you pass it a class derived from HttpContent and HttpClient will request a stream from the HttpContent which it can read from and will subsequently write out to it's internal request stream. This meant that about 75% of the Http transport was basically a rewrite. We encapsulate the request message inside our own HttpContent class and when the request bytes are needed, we use the MessageEncoder to encode the message and then return that. This works well because the channel layer abstraction boundaries are cleanly observed.

The problem with MTOM is that how it's implemented on the full framework the clean api boundaries between the transport and MessageEncoder were trampled on by a herd of angry elk. With the reversal of data flow (HttpClient pulls from HttpContent instead of WCF pushing to HttpWebRequest's request stream), we will need to do a complete rewrite of the MTOM feature and probably refactor the current code so that HttpRequestMessage/HttpResponseMessage are the encapsulation boundary instead of HttpContent.

If I was working on this full time with no other tasks to work on, I would estimate it would take me about 2 months to get it to a preview state. We're aware there are some shortcomings in the full framework implementation such as the inability to precisely control which fields are placed into their own multi-part section and which are serialized inline so any rewrite would also have an eye to making sure we have a path to exposing a clean way to control this as it has been a major pain point for some.

Hopefully this explanation helps you understand why we haven't simply ported the feature at this point.

[felipecaputo]

@mconnew, first of all, thanks for your feedback about this topic. I don't know the framework too well, but with the right direction I would really like to do it, having the right direction to do it.

It seems really a complex implementation but, may more people would like to help if you can spare some time in tutoring or breaking it into small implementations we could do to take advantage of the OpenSource community?

Do you think it could be possible?

[malsoft-pl]

Same problem(

Does anyone know how to write it?

var myBinding = new WSHttpBinding();
myBinding.Security.Mode = SecurityMode.Transport;
myBinding.Security.Transport.ClientCredentialType = HttpClientCredentialType.None;
myBinding.MessageEncoding = WSMessageEncoding.Mtom;

[ghost]

I have this response from a service:

--MIMEBoundary_59f98a3b863640e46b622e5739083846dab4b1825abc60d0
Content-Type: application/xop+xml; charset=UTF-8; type="text/xml"
Content-Transfer-Encoding: binary
Content-ID:
[e-mail]

--MIMEBoundary_59f98a3b863640e46b622e5739083846dab4b1825abc60d0--

1162898
2018-03-13T15:08:30.119+01:00

How can I convert it easily to an xml? I have the class created from the xsd, but the MTOM header is annoying me.....

[mananchoksi007]

Receives Below Error while calling the post method on WCF service passing xml parameter

0202Unable to unmarshal XML stream. Please verify and resubmit.::Premature end of file.Invalid input

Its successfully working with .Net Framework. Is there different way to post the xml content then .Net framework soap service call?

[lalenzos]

Are there any news regarding ASP.NET Core and SOAP MTOM?

[brux88]

are there news?

[jducobu]

Non news ... :(
Personaly, i added a binding supported by .net core and use it

[Trapulo]

I moved my WS to the old .NET 4.6 and WCF :(

[brux88]

I have a .net core project, I created another .net 4.5 project to be able to use mtom. this last project the amount in my project core.net. but it gives me an error:Method not found: 'Void System.ServiceModel.BasicHttpsBinding.set_MessageEncoding(System.ServiceModel.WSMessageEncoding)'.

why?

[mananchoksi007]

Same, I had also put that service call in to .net Framework as .net core
wont be able to handle that. Thats so disappointing

On Mon, Oct 29, 2018 at 12:39 PM brux88 [e-mail] wrote:

I have a .net core project, I created another .net 4.5 project to be able
to use mtom. this last project the amount in my project core.net. but it
gives me an error:Method not found: 'Void
System.ServiceModel.BasicHttpsBinding.set_MessageEncoding(System.ServiceModel.WSMessageEncoding)'.

why?

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/dotnet/wcf/issues/1810#issuecomment-433981569, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AckWhyPJAJxjnqr_Reky1OEuvzINR-lvks5upy9RgaJpZM4McRio
.

[JohnTobia]

This is one of my organizations only blockers moving to .NET Core. We have a document management platform that returns large documents using MTOM (that we have no control over). We have successfully written a wrapper using the XmlMtomReader class targeting net472. We really just need XmlMtomReader and XmlMtomWriter ported to .NET Core. I realize that the HttpClient/WCF stuff is more involved, but would it be possible just to get the underlying classes implemented?

[felipecaputo]

Non news ... :(
Personaly, i added a binding supported by .net core and use it

@jducobu Can you share how did you did it?

[cesaralc]

Hi, Any update? This is a fairly important feature.

[brux88]

Non news ... :(
Personaly, i added a binding supported by .net core and use it

@jducobu Can you share how did you did it?

yes its possible share how did you did it?

[napalm684]

Agreed sharing is caring :-)

[jducobu]

Mtom was abandonned in 2012 by microsoft because the protocol is slower than json. Instead of using Mtom binding, i use a basichttpbinding (or something like that). But for that, the service must be configured to use this binding configuration. Itks possible to change the binding in web.config file.

[LokiMidgard]

Unless you consume someone elses Service where you can't change any configuration.

[jducobu]

I understand. In my case i have chance the service provide also httpbasic supported by .net core. You can also offered a wrapper behind the wcfservice in rest in .net framework using mtom if it's the only binding the service offers. I'll do that if i'm in your situation

[Trapulo]

I understand that Mtom can be "dead". But interoperability is interoperability. For example, in Italy the government has created a mandatory service to manage all invoices of all country. Every company may use it. And this service is based on IBM+Java (ok, I know... sorry, we're in Italy, we like to be late) and requires Mtom. So, every ERP based on .NET cannot be in .NET Core and will require some legacy module in WCF 4 to bridge the two world.

[felipecaputo]

@Trapulo Not just Italy has legacy integrations that uses Mtom, here in Brazil the software that runs on some law courts that provide a mandatory integration to others law courts is mandatory and uses Mtom too.

We are having the same problem and this is the only thing that is blocking us to migrate our services.

[napalm684]

A vendor product is our issue. We don't control the service implementation of OpenText.

[cruentusmors]

Trying to consume web service from peoplesoft using .net core - this needs to work

[hickmanjos]

It's also still widely used in the states, the IRS is still using MTOM.

(I'm currently on the path of restarting my project with .net framework)

[brux88]

at today nothing news? :(

[brux88]

there is a guide to be able to deserialize a mtom in aspnet core

[felipecaputo]

@brux88 Are you asking if there is a guide? Or telling that there is a guide because, if this guide exists, I'ld love to read it.

[brux88]

@felipecaputo I'm looking for a guide, I can not believe that this issue has not been put even in the next milestone for two years, so I wanted to know if there were other ways to avoid the problem

[felipecaputo]

@brux88

I can not believe that this issue has not been put even in the next milestone

Me too, Mtom is old, I know, but it is entreprise level, and there is a lot of old webservices that problably will take a lot of time to be outdated and we need it

[felipecaputo]

Hi @Lxiamail it would be possible to have some definitions / specification about how this should be implemented and maybe the community could provide the implementation...

I really thing that this would make a lot of people really happy o>

[JohnTobia]

@felipecaputo see my comment above. To start, we really just need XmlMtomReader and XmlMtomWriter ported to .NET Core. I have a working solution (by all means not optimal) if those classes exist. It's at least a starting point.

[felipecaputo]

@JohnTobia I'll take a look when I get home today, maybe I can help and end up submitting a PR

[kfrancis]

@felipecaputo @JohnTobia I'd be willing to donate my time to this issue. We need this. I need a .NET Standard compatible library. How can we organize and get this done?

@JohnTobia Can you gist what you've done that works in your scenario?

[naveen4854]

Any update on the Mtom support?

[chrisengelsma]

Doubling down on how important this feature is to those of us who are reluctantly clinging to .NET framework solely for Mtom support

[tstefansson]

Any update on the Mtom support?

[brux88]

@Lxiamail please any update on the mtom support

[Lxiamail]

Unfortunately, we don't have any further update on this. We also considered to define a spec so that community may be able to help to do the implementation. However, as Matt commented above, the primary complexity is redesign the feature on .NET Core. The investigation cost to define the spec will be high that we can't afford at this point.

[felipecaputo]

@Lxiamail, if we analise and make a spec proposal, the team would take a look and evaluate it?

I think that, if community work togeter and we make a good spec, maybe it could be good for both!

[mconnew]

Hi @felipecaputo. Having the community implement MTOM would be great. In the next couple of days I'll write up a quick summary of my thoughts on how to bring in MTOM support including some potential design ideas I've had for a whiile to improve interop with other stacks, and then you can come back with a spec proposal. Does that sound like it would work for you?

[felipecaputo]

That would be great.

I'll wait for these ideas, and take a look at the source and documentation to get ready.

Thank you @mconnew

[kfrancis]

Adding a specific chat room for us to discuss: https://gitter.im/wcf-mtom/community?utm_source=share-link&utm_medium=link&utm_campaign=share-link

[jducobu]

https://www.w3.org/TR/soap12-mtom/

[mconnew]

So here's my brain dump on the topic of MTOM. I've had two strong goals when porting WCF to .NET Core.

Make code simpler
Internally we've mostly dropped APM implementations and everything is Task based. The sync code path has also been dropped and just calls the Task based API's.

Own less code
WCF on .NET Framework was developed when a lot of what is now taken for granted as existing in the framework just didn't exist so there's a lot of wheels which were invented which have been reinvented and now available generally in the rest of the framework. Nobody went back and removed the WCF implementation and switched to the general one. So the .NET Framework implementation is a lot bigger than it needs to be.

There's some problems with the MTOM implementation which I've become aware of from customers over the years while working on .NET Framework. There are two I'd like to address in a .NET Core implementation. The first one is lack of control in which elements get moved out to separate parts in the HTML multi-part message and which ones get serialized as part of the XML body. The MTOM spec is not opinionated on this and WCF has a heuristic to make this choice. There are some other SOAP stacks which don't like WCF's heuristic. So we should add a mechanism to override the heuristic decision for individual elements to improve interop capability with other stacks. The second problem is the .NET Framework implementation is not extendable through either derivation or encapsulation. The behavior needs to be modifiable by either encapsulation or derivation as there have been multiple issues developers have had over the years which could have been easily addressed if the MTOM encoder behavior could be modified in one of these ways.

The .NET Core implementation of HttpTransportBindingElement is almost a rewrite of the code from .NET Framework. This was needed due to HttpWebRequest not being available (there's a class there now, but it has many undesirable behaviors like forced buffering of the request and isn't the real thing). So the transport was redone using HttpClient. The HttpRequestMessage content is a custom type System.ServiceModel.Channels.MessageContent in order to do things the HttpClient way. Conceptually it lazily does the work of encoding the message when HttpClient is ready to send the body. The reason for this is streamed transfer mode prohibits creating the body up from.
There is a class System.Net.Http.MultipartContent which looks like a good candidate for use with MTOM. This is the principal of "own less code". There are going to be lots of edge cases in the implementation of Multi-part entity bodies and I prefer if those edge cases were somebody else's problem :). Building on top of MultipartContent will simplify the code a lot. The class also has been written in a way to be convenient to derive so we might want to consider making an MtomMessageContent class which derives from MultipartContent. That might not be necessary though as it's a container of a list of innner HttpContent objects and this inner objects can generate their byte stream lazily.

[lennykean]

I developed a workaround to support MTOM in .net core wcf.
https://github.com/lennykean/WcfCoreMtomEncoder

This is really a workaround that is only meant to consume existing mtom soap services, but I think it could evolve into a full implementation of mtom in .net core.

[mconnew]

@lennykean, this looks like a great start. I've had a look at the code behind the ReadAsMultipartAsync method and it has one really big flaw. It reads the entire contents into memory. The typical usage I've seen with the MTOM encoder has been when needing to transfer large amounts of data over a SOAP service. Normally SOAP will encode a byte[] as base64 encoded string which increases it's size by ~30%. This is a lot when transferring 200MB of data. MTOM doesn't really gain you much unless you are sending large amounts of data. It might be possible to use the building blocks in the Microsoft.AspNet.WebApi.Client package to build something better. Basically an implementation of ReadAsMultipartAsync needs to lazily create each of the contained HttpContent objects. The HttpContent parts also need to return a stream from ReadAsStreamAsync which isn't backed by an in memory buffer but read from the actual network stream and fake an EOF once the part has been completely read.
What you've provided is great if you aren't returning a large amount of data, and the limitations are mainly in the Microsoft.AspNet.WebApi.Client code.
Edit:
I just asked a colleague on the ASP.NET Core team if there was a nicer implementation and he pointed me to this. You can see some sample usage here. It looks like it wouldn't take a lot of work to switch to using that implementation which solves these problems.

[matthiaslischka]

Any updates or reasonable workarounds for big data streaming via mtom?
We need to stream-download big files via SOAP mtom in dotnet core.

[RealHabix]

zhenlan commented on Sep 28, 2017
Not in a plan at this point. Please upvote if this is important. It will be helpful for future planning.

How much more upvote and time do you guys need (since it's in backlog for 2+ years)?

[DiegoAndes]

2020 and we still don't have the implementation :'(

[craffael]

I successfully used https://github.com/lennykean/WcfCoreMtomEncoder to read mtom messages. However for writing it doesn't work yet...

[matthiaslischka]

This was already mentioned above. Keep in mind that it does not support streaming, the main advantage of MTOM.

[xtrem14]

I developed a workaround to support MTOM in .net core wcf.
https://github.com/lennykean/WcfCoreMtomEncoder

This is really a workaround that is only meant to consume existing mtom soap services, but I think it could evolve into a full implementation of mtom in .net core.

Thank's for this.
May not working with HttpsTransportBindingElement :/

when will MTOM support...

[LokiMidgard]

@xtrem14 I have it working with https without problems.

See Client service missmatch issue.

[xtrem14]

@LokiMidgard thanks for your reply.

I initialized the version of the messages in Soap11.
I now get a whole other error: _A security error was encountered when verifying the message_

at System.ServiceModel.Channels.ServiceChannel.HandleReply(ProxyOperationRuntime operation, ProxyRpc& rpc) at System.ServiceModel.Channels.ServiceChannel.EndCall(String action, Object[] outs, IAsyncResult result) at System.ServiceModel.Channels.ServiceChannelProxy.TaskCreator.<>c__DisplayClass1_0.<CreateGenericTask>b__0(IAsyncResult asyncResult) at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw() at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task) at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) at System.Runtime.CompilerServices.TaskAwaiter1.GetResult()`

I admit that I don't really understand this error ...

[LokiMidgard]

@xtrem14 Unforuntaly For me it just worked that way and I havn't worked with it in some time. According to a stackoverflow question you may find a more specific error in the event log.

[xtrem14]

@LokiMidgard i found my problem, this was due to a WS security problem.
Also not supported by WcfCore.

I solved this one thanks to this solution: https://bbrauns1.wordpress.com/2019/11/07/how-to-add-soap-ws-security-usernametoken-profile-to-net-core-3-0-client/

[mconnew]

@xtrem14, we do support usernametoken profile. If you use WSHttpBinding with security mode TransportWithMessageCredentials and client credential mode of Username, it should all work. You might need to turn off establish security context if the remote endpoint isn't using WS-SecureConversation.

[xtrem14]

@mconnew, i had actually considered this solution, but WSHttpBinding does not seem to be available in .NET Core : https://docs.microsoft.com/fr-fr/dotnet/api/system.servicemodel.wshttpbinding?view=netframework-4.8&viewFallbackFrom=netcore-3.1

[mconnew]

@xtrem14, that's a documentation issue. It's definitely there.

Edit: Actually, there isn't a documentation issue. WCF is part of platform extensions. If you check the docs here: https://docs.microsoft.com/dotnet/api/system.servicemodel.wshttpbinding?view=dotnet-plat-ext-3.1 you should see it's available.

[mjehle82]

Is there a time schedule for the MTOM support?
My project will run for the next two years. It would help us decide which way to go.

[yalin78]

Is MTOM supported with .net core now? When is it going to be available?

[ericnewton76]

So I thought I'd mention this here, since I had to spend an hour or so fully understanding whats going on:

WCF for Net Core made an architectural decision without realizing it prevented MTOM encoding efficiently.
WCF for Net Core team do not want to rearchitect WCF for Net Core.
WCF for Net Core is now recommending gRPC instead.

https://docs.microsoft.com/en-us/dotnet/architecture/grpc-for-wcf-developers/why-grpc

Do I have this right?

[ericnewton76]

Also of note, an external mtom encoder was created: https://github.com/lennykean/WcfCoreMtomEncoder

However, I must stress that due to the architecture limits placed by WCF for Net Core, this WcfCoreMtomEncoder is VERY MEMORY INTENSIVE (according to users of its current implementation, I havent fully examined it myself yet). Meaning, it has to keep the whole contents in memory before it can emit a valid soap message to the client, which is a suboptimal but workable way to accomplish this.

[RealHabix]

So I thought I'd mention this here, since I had to spend an hour or so fully understanding whats going on:

WCF for Net Core made an architectural decision without realizing it prevented MTOM encoding efficiently.
WCF for Net Core team do not want to rearchitect WCF for Net Core.
WCF for Net Core is now recommending gRPC instead.

https://docs.microsoft.com/en-us/dotnet/architecture/grpc-for-wcf-developers/why-grpc

Do I have this right?

Yes, yes, yes. But what should we do about legacy services that require MTOM - we use plenty and they won't be updated any time soon. Also the WcfCoreMtomEncoder doesn't support streams. Only useful in special cases.

WCF team let us and our customers down big time. We had to switch back to .net framework in many cases.

[mdora7]

I developed a workaround to support MTOM in .net core wcf.
https://github.com/lennykean/WcfCoreMtomEncoder

This is really a workaround that is only meant to consume existing mtom soap services, but I think it could evolve into a full implementation of mtom in .net core.

As far as I understand, I am thinking this just manipulate response part therefore it not possible send request with mtom coding. I already tried in code but message still going with soap+xml.
You already said but I wanna make notice to those who read this. Also thanks for library

[nalincb]

Recently we wanted to upload files to a WCF service (which used MTOM encoding) from a .NET Core 3.1 client. Below is what worked for us at the end. Hope this will help someone.

var textMessageEncodingBindingElement = new TextMessageEncodingBindingElement
                    {
                        MessageVersion = MessageVersion.Soap11,
                        ReaderQuotas =  { ... }
                    };

var mtomMessageEncoderBindingElement = new MtomMessageEncoderBindingElement(textMessageEncodingBindingElement);
var transportBindingElement = new HttpTransportBindingElement { ... };

var binding = new CustomBinding(mtomMessageEncoderBindingElement, transportBindingElement);
var channelFactory = new ChannelFactory(binding, new EndpointAddress("endpoint"));
var channel = channelFactory.CreateChannel()

[andersonaap]

@nalincb, should it be?

var binding = new CustomBinding(mtomMessageEncoderBindingElement, transportBindingElement);

it works for me.

[nalincb]

@andersonaap , yes that was a mistake and I updated code. Cheers.

[airhawk777]

Is there ETA on this one?
We are trying to do some long term planning and are keen to move to .NET 5, but this is looking like the only impediment. Changing the server is not an option since its a government service that we consume and have no control over.
Issue is three years old and made 'Priority 1' nine months ago, but it looks like there has be no traction in that time. Is Microsoft committing to this piece of work or still undecided?

[RealHabix]

Is there ETA on this one?
We are trying to do some long term planning and are keen to move to .NET 5, but this is looking like the only impediment. Changing the server is not an option since its a government service that we consume and have no control over.
Issue is three years old and made 'Priority 1' nine months ago, but it looks like there has be no traction in that time. Is Microsoft committing to this piece of work or still undecided?

Milestone
6.0

[mconnew]

As @RealHabix pointed out, the plan is to have this work completed for the release which aligns with the .NET 6 release. Note that we still only depend on netstandard 2.0 so we won't have a requirement of .NET 6 to use it. All currently supported versions of .NET/.NET Core support netstandard 2.0 so there shouldn't be forced to update your application to use it. This will continue to be our plan until there's a feature that requires .NET 6.

[NicholasNoise]

6.0 Preview 2 is already here, but XmlDictionaryReader.CreateMtomReader still throws exception.
Any news?

[tclopes]

Any news about supporting MTOM?