1
votes

Migrating from .Net Framework to .Net Core 3.1 and need to convert a WCF tcp/mex client. My attempts to create the client result in: "No endpoints compatible with .Net core apps were found". The Visual Studio 2019 tool to generate a connected client is titled: "Microsoft WCF Web Service Reference Provider". This makes me ask if the tool only works with web http/wsdl endpoints and will not work with tcp/mex?

Another clue is that the generation results in a "Warning: cannot import wsdl binding". That makes sense since the 'definition language' is mex. (P.S. If I create the client using .Net Framework in Visual Studio 2017 against the same endpoint it works just fine so the endpoint is valid.)

Even if .Net Core will work with tcp/mex ultimately I need to decide if this is worth the effort or should I bite the bullet and convert to gRPC?

2
That is a 5 year old post relevant to .Net Framework but not to .Net core which is the heart of my question.user610342
Why would change be different now than 5 years ago (adding MEX endpoint)? Looks like besides going to core you are also adding the mex. Did mex work Net Framework?jdweng
The first version of .Net Core was released in 2016 and did not support any form of WCF communication until .Net Core 3 released in 2019. I am not adding mex - it has been part of the .Net Framework service since I put it into production in 2015 and has run flawlessly. A 5-year old article cannot address the features of a product (.Net Core 3.0) just released last year which I wish to migrate to.user610342
It wasn't clear that you had MEX working with Net. There have been lots of issues with people going from Core 2.0 to 3.0/3.1. This may similar to other 3.0/3.1 issues. Did you check endpoint value? Is it a V4 or V6?jdweng

2 Answers

1
votes

"Microsoft WCF Web Service Reference Provider" supports tcp/mex, you need to add mex endpoint in the code.

               selfHost.AddServiceEndpoint(typeof(ICalculator), new NetTcpBinding(), "CalculatorService");

                // Step 4: Enable metadata exchange.
                ServiceMetadataBehavior smb = new ServiceMetadataBehavior();
               // smb.HttpGetEnabled = true;
                selfHost.Description.Behaviors.Add(smb);

                Binding mexbinding = MetadataExchangeBindings.CreateMexTcpBinding();
                selfHost.AddServiceEndpoint(typeof(IMetadataExchange), mexbinding, "mex");

After the service runs successfully, "Microsoft WCF Web Service Reference Provider" can successfully generate a proxy class based on the URI.

enter image description here

1
votes

I got a response from an MSFT support person saying while WCF Web Service Reference provider will import tcp/mex metadata the solution does NOT fully support Message security (I assume this also means it does not support Transport Message security either.) Perhaps the tool is generating "No endpoints compatible with .Net core apps were found" because it detects Message security. Would be clearer if it noted why it did not find a compatible endpoint cause that endpoint is in production currently (and as I say works with .net Framework.)

For me, Message security is more important than TLS security because it provides Authorization. To wit: if you don't have the cert you cannot talk to me. This is a show-stopper and when combined with the fact that I cannot generate the server component in .Net Core these are deal-breakers. Message security has been pushed out of .Net 5 (for November release) and so may not appear till .Net 6.

I already have a gRPC protoype working in less time than it took me to research this .Net core issue so I am moving on.