where should I put the code for configuring AutoMapper mapping between DTO and EntityFramework Entities for WCF PerSession services?
If in the default constructor, does that mean every session will create an individual mapping and causes lots of overhead on the server side?
Thanks
Configuration of AutoMapper is global for the whole application so your service should not do any configuration itself. AutoMapper should be configured in your application bootstraper (when the application starts). For example in WCF service hosted in IIS (over HTTP) you can use standard Global.asax and Application_Start.
Related
I have a WCF service which programmatically creates its endpoints rather than using a config file - I'm looking into this as our field engineers are prone to break XML easily and we may use different types of binding in different scenarios.
This works well in self-hosted environments (console app, windows app) and as a Windows Service.
Can I do this with a service in IIS or do I have to provide a .SVC file for each endpoint ?
Also will the endpoint address from the client end have to include the .SVC extension ?
This is not a service intended to be used by third parties, only by our client components. We may expose parts of our API later but not initially.
If you're using .NET Framework 4.0 (and later), you can use the ASP.NET routing integration to define a service using a custom ServiceHostFactory implementation. A few things you'll need:
In web.config, set the attribute aspNetCompatibilityEnabled on the <system.serviceModel / serviceHostingEnvironment> element to true
Add a global.asax / global.asax.cs file, and in the Application_Start add a new ServiceRoute to the ASP.NET RouteTable.Routes collection. The service route requres you to define a new service host factory, where you can define your endpoints programmatically.
With that you'll be able to have endpoints without the ".svc" in their addresses. You can also use the service host factory without using routes, by creating a .svc file for each service (not endpoint), and using the Factory attribute in the <%# ServiceHost directive.
For more information about service host factories, check the post at http://blogs.msdn.com/b/carlosfigueira/archive/2011/06/14/wcf-extensibility-servicehostfactory.aspx.
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.
I currently have a HttpModule that generates a unique ID per external client request, appends it to the IIS log, and adds it to the HttpContext.Items collection in order to pass in on the thw web service.
I am currently replacing the web service with a WCF service (still hosted under IIS). I can successfully do the same process by enabling AspNet compatibility, but I would prefer not to. Is there any way to pass data from a HttpModule to say the OperationContext of the WCF service without enabling AspNet compatibility?
This is what MSDN has to say,
HttpModule extensibility: The WCF hosting infrastructure intercepts WCF requests when the PostAuthenticateRequest event is raised and does not return processing to the ASP.NET HTTP pipeline. Modules that are coded to intercept requests at later stages of the pipeline do not intercept WCF requests.
I suggest you go through this MSDN documentation completely to understand how ASP.Net and WCF coexist
I'm developing a .NET 2.0 client application that needs to connect to a WCF service. I add a web reference to a basicHttpBinding WCF service that we've developed and VS creates the proxy class and the config paraphenalia which is fine. The problem is that I only want to use a small fraction of the methods that the WCF service implements and not carry around the extra implementations that the client app doesn't need.
I was thinking of creating a different basicHttpBinding endpoint and put the methods there. Is there a way for only one endpoint of a WCF service to be referenced by a .NET 2.0 project?
Regards,
Frank
When you add a web reference to a service, you always get all the service methods. It's the service (implementation) that defines the scope of what ends up in the WSDL.
The only option to limit the scope of the method your client generates would be to create a second WCF service on the backend, which only implements those few methods that you want in your client - just having a second endpoint won't really help.
So I already have a working implementation of StructureMap with the WCF service (including custom instance provider, behaviors, etc.)
When I try to have an object that is instantiated only once per user request, I use the InstanceScope.HttpContext and it throws because the context is null.
Do anyone have a proper way of doing that?
On the server-side of the WCF service? By default, WCF has nothing to do with ASP.NET and thus all your HttpContext etc. aren't there.
By default, your WCF services will be called on a "per-call" basis, e.g. each request gets a brand-new, separate, totally isolated instance of your service class. Why not just put those things into the service class as internal fields??
Or you might want to check out this blog post on how to abstract request state and providing sample implementations for ASP.NET (using HttpContext.Items) and WCF.