how to use ASP.NET session in WCF? - wcf

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

Related

HttpModules in Self-Hosted WCF Service

We have a windows service that is self-hosting a WCF Data Service, using the DataServiceHost class. Everything is working just fine, but we would like to hook up some HTTPModules to the service, if possible. One of the HTTP Modules would be for custom basic authentication, the other for auditing (including responses, which is why an HTTP Module works so well for this).
Keep in mind that we are running as a regular windows service, so we have no web.config, the service is not hosted by IIS, and it is not an ASP.Net application.
So, my questions are:
Is it possible to have an HTTP Module listen on a self-hosted WCF data service?
If this is not possible, what options would I have that are similiar to the power of an HTTP Module?
WCF doesn't operate on the same request pipeline as standard ASP.NET applications, although you can take advantage of a number of ASP.NET features (like session) if you configure your service for ASP.NET compatibility.
[AspNetCompatibilityRequirements(RequirementsMode = AspNetCompatibilityRequirementsMode.Required)]
However, it looks like you just need something that will let you jump into the pipeline the way that HTTPModules do for an ASP.NET Application. That being the case, there are plenty of options. You can check out this page for a lot of samples.
You mentioned authentication, and there are plenty of options built into WCF that can save you from rolling your own solution. Check it out here.

WCF REST and asp.net and debugging

I have an asp.net 4 application that hosts a WCF REST service via WebServiceHost...
WebServiceHostFactory factory = new WebServiceHostFactory();
routes.Add(new ServiceRoute("mss", factory, typeof(ModuleStorage)));
My application has a custom authentication module and requires IIS Anonymous access. I also have Windows Integrated so that I can debug my application.
The issue I am having is the WebHttpBinding created by the WebServiceHost does not support having two authentication methods enabled in IIS. I can turn off Win. Auth. and it works but I can not debug.
So my question is... Can I enable WebHttpBinding to support both or can I somehow enable debugging without Win. Auth.
This service must be hosted as part of the application and I need a way to debug it.
Try debugging WCF REST Service using Fiddler, see the following links for more informations :
http://www.codeproject.com/Tips/213007/Debug-WCF-REST-Service
Depends what you are trying to debug. You could always trace the WCF service using SvcTraceViewer. Here is the config you can use on the server.
I ended up using ASP.NET Web API. I have to say so far I am a big fan!
http://www.asp.net/web-api

Ninject Di bindings using a WCF service

I recently created a WCF service library. I am planning on hosting it in IIS. Since I want to reuse my repository layer I decided to go use Ninject in my WCF service as well (I use it in other projects in the solution).
I installed the Ninject Wcf Extensions. I configured it using the NinjectServiceHostFactory in the svc file. I added a Global.asax file to override the CreateKernel() that inherits from NinjectWcfApplication but I am not sure if I am using the bindings correctly. I first started with:
Bind<IUnitOfWork>().To<UnitOfWork>().InRequestScope();
But I quickly realized that this does not work since no data was saved to my database. It appears that the WCF service does not use the ASP.NET pipeline. I went ahead and tried both of these as well just to see if my data was committed to the database:
Bind<IUnitOfWork>().To<UnitOfWork>().InThreadScope();
Bind<IUnitOfWork>().To<UnitOfWork>().InTransientScope();
No luck. I then decided to try:
Bind<IUnitOfWork>().To<UnitOfWork>().InSingletonScope();
This worked but I don't want my database context to be shared by every single request that comes in to the WCF service. I then did some research and found the following approach:
Bind<IUnitOfWork>().To<UnitOfWork>().InScope(c => OperationContext.Current);
This works but is it correct? I wan t something to resemble the InRequestScope for a MVC application. Each request to the service should get its own Database context.
I suggest to have a look at the latest build from the CI-Server http://teamcity.codebetter.com
You need Ninject, Ninject.Web.Common, Ninject.Extensions.Wcf
With this version you can use InRequestScope for Wcf.
I am new to Ninject, but I can tell you that OperationContext.Current is the equivalent to HttpContext.Current for web application.
So your first thought was to use .InRequestScope(); (which is equivalent to .InScope(c => HttpContext.Current);)
so I guess that using .InScope(c => OperationContext.Current); for WCF is pretty correct.

WCF service with HttpContext

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);

Converting ASMX to WCF Web Service

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