Moving WSHttpBinding to BasicHttpBinding....
Problem statement: WSHttpBinding is not supported in .Net core.
When my application was in .Net 4.6, I was using WSHttpBinding to create the connection with WCF with below code.
var binding = new WSHttpBinding(SecurityMode.TransportWithMessageCredential);
binding.Security.Transport.ClientCredentialType = HttpClientCredentialType.None;
binding.Security.Message.ClientCredentialType = MessageCredentialType.Certificate;
binding.Security.Message.EstablishSecurityContext = false;
X509Store store = new X509Store(StoreName.My, StoreLocation.CurrentUser);
store.Open(OpenFlags.ReadOnly);
var cert = store.Certificates.Find(X509FindType.FindByThumbprint, "Thumprint", true)[0];
result = new MyClient(binding, address);
client = result as ClientBase<TInterface>;
client.ClientCredentials.ClientCertificate.Certificate = cert;
Now I am migrating my application to .Net core and i found there is no support to WSHttpBinding.
I am planning to move with BasicHttpBinding and made the following changes:
var binding = new BasicHttpBinding(BasicHttpSecurityMode.TransportWithMessageCredential);
binding.Security.Transport.ClientCredentialType = HttpClientCredentialType.None;
binding.Security.Message.ClientCredentialType = BasicHttpMessageCredentialType.Certificate;
With BasicHttpBinding there is no provision to below code:
binding.Security.Message.EstablishSecurityContext = false;//This code is w.r.t. WSHttpBinding.
So, my question is: Does this changes okay to go with or I should do some other way around?
Please assist!
in .NET Core & .NET 5
BasicHttpBinding and WSHttpBinding
Solved for me by installing Nuget package System.ServiceModel.Http Version 4.8.1
https://www.nuget.org/packages/System.ServiceModel.Http
Run this command in Package Console Manager in Visual Studio
Install-Package System.ServiceModel.Http
In .Net 5, Wshttpbinding no longer supports SecurityMode Message. Use Transport instead. However, it is not as secure as Message.
var binding = new WSHttpBinding();
binding.Security.Mode = SecurityMode.Transport;
https://learn.microsoft.com/en-us/dotnet/framework/wcf/how-to-set-the-security-mode
Wshttpbinding is supported in .net core 3.1.
You should use the Nuget --System.private.serviceModel to get the wshttp binding methods in .NET core 3.1
Below are the Nuget Packages that will be required.
I did the same (move from FULL .NET FRAMEWORK to .NET CORE PROJECT) and i found there is NO SUPPORT for WCF ...
what i have done is:
1 - Create a .NET STANDARD LIB PROJ .. with reference to your SOAP endpoint (it support WCF)
2 - Reference your LIB to a .NET CORE PROJECT
hope it helps you!!
like:
and then reference it like:
Related
I use a asp.net core 2.0 web api with a connected wcf service.
On normal asp.net i can configure the basicHttpBinding in the web.config. But i can't find any solution to configurate the basicHttpBinding in asp.net core.
I have to set the transferMode="Streamed" and maxReceivedMessageSize="128108864".
Edit: it is a asp.net core 2.0 web api but with a full .net target framework
I have just encountered similar problems. So it seems that web.config is no longer available, because it's only used in IIS, and since Asp.net core 2 doesn't need IIS, web.config is irrelevant. I did try to add it though, but it wouldn't work.
Best thing is to do it programmatically.
BasicHttpBinding vidiBinding = new BasicHttpBinding();
vidiBinding.MaxReceivedMessageSize = 2000000;
EndpointAddress myEndPPtAdd = new EndpointAddress("http://localhost:9200/SilverlightVidiCloudService");
VidiExternalCloudServiceClient myClient = new VidiExternalCloudServiceClient(vidiBinding, myEndPPtAdd);
await myClient.OpenAsync();
I'm attempting to call a web service from a VB .NET 3.5 Win Forms application. I have been able to create a Service Reference but when I call the web service I receive the SOAP fault:
A SOAP 1.2 message is not valid when sent to a SOAP 1.1 only endpoint.
The web service uses username and password authentication with a certificate. I also need to connect to different URLs depending on the environment (development or production). For these reasons I was attempting to use a WSHttpBinding created in code. However, it appears that type of binding assumes SOAP 1.2. I've been told by the author of the web service that they are unable to support SOAP 1.2.
Is there a way, either with the WSHttpBinding or a CustomBinding in code, to consume a web service that only supports SOAP 1.1 using a WCF Service Reference?
Dim binding As New System.ServiceModel.WSHttpBinding
binding.Security.Mode = ServiceModel.SecurityMode.Transport
binding.Security.Transport.ClientCredentialType = ServiceModel.HttpClientCredentialType.Basic
Dim service As New ServiceReference.ServiceClient(binding, New System.ServiceModel.EndpointAddress(baseUrl))
service.ClientCredentials.UserName.UserName = serviceUsername
service.ClientCredentials.UserName.Password = servicePassword
Any help is appreciated!
I'm helping someone use Visual Studio Tools For Applications to connect an Infopath application to a service written using WCF that requires a username and password be sent in the SOAP header (clientCredentialType="UserName"). The service is using basicHttpBinding.
Infopath 2010 relies on Visual Studio Tools For Applications 2005 and so I am stuck having to add a "Web Reference" instead of a "Service Reference". I have never had to do this before and it is becoming very problematic trying to figure out how to do it.
In a Service Reference I just say:
service.Credentials.UserName.UserName = "username";
service.Credentials.UserName.Password = "password";
But when consuming using a Web Reference the Credentials property behaves differently and I can't get it to pass the username and password in the SOAP header automatically.
I have tried a few things including these with no luck:
MyService service = new MyService();
CredentialCache cache = new CredentialCache();
// I've tried "Basic" and string.Empty as well in the place of "UserName"
cache.Add(new Uri(service.Url), "UserName", new NetworkCredential("username", "password"));
service.Credentials = cache;
service.PreAuthenticate = true;
service.MyMethod();
and
MyService service = new MyService();
service.Credentials = new NetworkCredential("username", "password");
service.MyMethod();
but have had no luck at all. Logging the entire message on the service, the username and password are not included in the SOAP header at all and I receive the following error: "An error occurred when verifying security for the message."
The answer really is just that you can't do it automatically from .Net 2.0.
There are reasons why WCF has replaced ASMX. Support for security standards is one of them.
If you're using VSTA, then I presume that you can use COM objects. You could create a COM object using .NET 3.5 (which is just .NET 2.0 SP2 plus some extra libraries). This COM object could use a WCF Service Reference to consume the service, yet would expose only COM. Any code that can consume a COM object would be able to consume your "proxy object".
I have a MonoTouch project using some code I share with a Windows Phone 7 app. This shared code creates a WCF proxy for a RIA Domain Service (using the /Soap endpoint), generated using SLSvcUtil.exe. This is what the code looks like:
BasicHttpBinding binding = new BasicHttpBinding();
EndpointAddress address = new EndpointAddress("http://someurl/someservice.svc");
var client = new MyDomainServiceSoapClient(binding, address);
client.CookieContainer = _cookieContainer; // <-- EXCEPTION here
This piece of code works in WP7, but fails in MonoTouch, and I can't find why. The exception I get in MonoTouch is:
System.InvalidOperationException: Unable to set the CookieContainer.
Please make sure the binding contains an HttpCookieContainerBindingElement.
at MyDomainServiceSoapClient.set_CookieContainer
I have tried the following options before setting the CookieContainer, but still the same error:
binding.EnableHttpCookieContainer = true;
binding.AllowCookies = true;
binding.CreateBindingElements()
.Add(new HttpCookieContainerBindingElement()); // ??
Update: I have also tried building a CustomBinding by hand and adding an HttpCookieContainerBindingElement but this also won't work.
Any ideas? The MonoTouch site tells me that the WCF implementation is "experimental", so maybe this is a limitation in the current version of MonoTouch?
I do not know how it is with SLSvcUtil.exe as the proxy generator with Monotouch, but I always used it in combination with Silverlight, as Silverlight is WP7 native, it is why it works there.
In MT you probably need to do it MT way, open the MonoDevelop and add the reference to the service from there so it is created using the Mono framework and its WCF proxy implementation rather than generated code for Silverlight service proxy.
At least, this works for me and works well to WCF services using basic HTTP binding.
It turns out that this was a bug in the Mono framework. As of MonoTouch 4.0.1, this is resolved, so I can use the above code without problems.
As the title says, I would like to consume a WF workflow using a ASP.NET 1.1 client.
The workflow is hosted on IIS as a .svc service.
I have a .NET 3.5 winforms test client that uses wsHttpContextBinding.
Because I need to put a WorkflowID in Context to have my workflow rehydrated and continued, I use this piece of code:
var Svc = new MyClient.MyService();
var Ctx = new Dictionary<string, string>();
Ctx.Add("instanceId", workflowID.ToString());
var CtxMgr = Svc.InnerChannel.GetProperty<IContextManager>();
CtxMgr.SetContext(Ctx);
Svc.MyOperation();
It's working fine this way.
Unfortunately, my ASP.NET 1.1 legacy appliction need to consume this workflow. I have setup an additional endpoint that uses basicHttpContextBinding.
I have read the context has to be passed to a cookie, and I'm stuck here as I have no clue about how to do this in the caller code.
MyClient.MyService Svc= new MyClient.MyService();
// How to set the workflowID ?
Svc.MyOperation();
How can I set the context with a workflowID in the cookie ?
Apparently, there is no miracle nor solution. The workflowID has to be handled to the client side, which concerns me because the client is not aware about the server plumbing.