I had a web service which I converted to wcf service with the same asmx extension. I have basicHttpbinding since my service talks to various clients like java, perl etc.
I had a validation which had HttpContext.Current in it. But I know this will not work in wcf service. I am trying to use RequestContext or OperationContext but am not able to do so. I tried to use
[ServiceBehavior(InstanceContextMode=InstanceContextMode.PerSession)]
but did not help. I am calling my service from soapUI for testing.
Ok, So I found the solution. There are quite some ways to get the HttpContext.Current context. Either we can use OperationContext or we can use the AspNetCompatibilityRequirements mode set to Allowed and aspNetCompatibilityEnabled set to true in web.config.
For my case where I had converted the asmx service to wcf service, I also had to modify the HttpHandler handler to remove and add asmx path to System.ServiceModel.Activation.HttpHandler.
You would better to use the OperationContext while using WCF services.
As you will always get the HttpContext.Current.Items is always Null which runs only while ASP.NET.
So add the following code:-
OperationContext.Current.Extensions.Add(extension);
Related
We have an existing wcf service, and I created a new project. I want to use it. I hit add service reference, pop in the URL, press OK, and it adds it as a service reference but there is no config generated.
I also tried svcutil.exe /language:cs /out:GeneratedProxy.cs /config:app.config [url] but no config is generated, only the proxy cs.
I'm using VS 2013 / .NET 4.0
My question is, is this a sign that the SVC itself has some missing data that is required to build the contracts, or is the problem with adding the service reference?
For the record I have tried unchecking the reuse types option which some questions on here have reported as fixing the problem.
Bonus question, do you think if I can't get this working that manually adding some generic default bindings and endpoint code to the web config will work?
First, the reason that why the Adding service reference generates nothing is that the WCF service is rest style service. By default, the proxy-based invocation of rest style WCF services is complex.
https://en.wikipedia.org/wiki/Representational_state_transfer
https://learn.microsoft.com/en-us/dotnet/framework/wcf/feature-details/wcf-web-http-programming-model
Calling the WCF rest style service with the client proxy is uncommon. Generally, we construct an Http request by using an HTTP client library to call the service, such as HttpClient, WebClient.
How to fix "ERR_ABORTED 400 (Bad Request)" error with Jquery call to C# WCF service?
Besides, calling the WCF rest style service with the client proxy is feasible. Please refer to my previous link.
WCF: There was no endpoint listening at, that could accept the message
Feel free to let me know if there is anything I can help with.
This is not a question about addressing.
I have an ASMX service, defined the usual way with WebService(), WebServiceBinding() and WebMethod() attributes.
Now, I'd like to use WCF to deliver this functionality, via self-hosted solution.
I've tried using ServiceContract() and OperationContract() attributes with equivalent Namespace parameters to what is in the ASMX service and even though the WSDL generated looks similar, when a client designed to work with the ASMX service posts to the WCF version, I don't see the methods being invoked.
How can I achieve what I'm trying to do?
how can I use ASP.NET session in WCF? or is there any alternative way to use "ASP.NET Session" like structure in WCF such as data storage?
Try having a look as ASPCompatibityMode with WCF and you then turn it on and share the session in the service method
You cannot use the ASP.NET session, since you can easily run a WCF service without having the ASP.NET engine fired up, eg. using a netTcpBinding.
There is however session handling native in WCF, where you can specify this on the service contract using the SessionMode parameter on the ServiceContract attribute.
See http://msdn.microsoft.com/en-us/library/ms733040.aspx for more details
In case anyone is still facing this issue (trying to use a SESSION variable in a .NET Web App consuming a WCF Service). Don't worry about the [AspNetCompatibilityRequirements .......] or adding aspNetCompatibilityEnabled="true" in the web.config.
After playing around with all that for a while I found out all I had to do was change each [WebMethod] within the _______.ASMX.CS to [WebMethod (EnableSession=true)].
So change [WebMethod] to [WebMethod (EnableSession=true)]. That's it.
I found out that from http://weblogs.asp.net/stevewellens/archive/2009/04/05/using-session-state-in-a-web-service.aspx
Thanks!
Bonsai
Writing a suite of IIS hosted WCF webservices (both GET and POST), and I need to be able to read a cookie for an authentication token so I know the user has been auth'd previously.
Will HttpContext.Current.Cookies give me what I need or is there something cleaner and more appropriate for a WCF web service with WebGet and WebInvoke attributes?
string cookieHeader = WebOperationContext.Current.IncomingRequest.Headers[HttpRequestHeader.Cookie];
works for me
I need to upgrade our web services to use WCF instead of ASMX. If the signatures of the web services stays the same, will existing clients that already call the ASMX service have to change anything on their end? Is there anyway to still use WCF but not force them to change anything?
Option 1 :
Using the current ASMX's WSDL, generate the client using svcutil.exe
Grab the generated interface and create a WCF service based on this interface
Output : One new WCF endpoint configured with basicHttpBinding. Clients need to update the URL at which they're sending the messages.
Option 2 :
Refactor your ASMX code. Move all the logic into a separate DLL.
Create a WCF service and use the logic in the refactored DLL.
Output : 2 endpoints, one for ASMX and another one for WCF
If you use the BasicHttpBinding for your new WCF service, and implement the same methods with the same message structure, existing callers should be able to call into this new WCF service without any change on their part.
There's also an AspNetCompatibilityRequirements attribute in order to get around some potential compatibility issue - see the MSDN documentation on it.
Marc