In a WCF REST service, hosted in IIS 7.5, .NET 4.03 or maybe 4.5...
is it possible to configure a .svc-less (file-less, extensionless) ServiceRoute in the web.config alone, without creating a Global.asax for RouteTable.Routes.Add, without IIS tricks, without HTTP modules, and not a RoutingService?
Thanks
No. The alternatives for svc-less, webhosted WCF services are the ones you listed. The most common ones are using the routing (RouteTable.Routes.Add) or IIS address rewriting (via a module). You could in theory write a "pure" ASP.NET project which forwards the requests to the .svc endpoint, but that is just a routing service in disguise.
Related
I have a RESTFul WCF service and it needs to be deployed now. I am really confused whether to deploy in windows service or IIS 7. I need to implement SSL also so the protocol would be HTTPS. It is just a simple service consumed by client using HTTPS protocol.
Please let me know which one is better.
Your question seems to have been asked (and answered) previously.
The following link provides a good discussion:
IIS WCF service hosting vs Windows Service
If your RESTFul WCF Service needs to be accessed via http (or https) protocol, then deploy in IIS7.
I've been looking into the possibility of using ASP.NET Web API and SignalR in a self-hosted application, and I noticed that the ASP.NET Web API self-hosted implementation uses WCF, and the SignalR self-hosted implementation uses System.Net.HttpListener. This makes it a little harder to come up with a combined self-hosting solution, but it does get me wondering why the different project teams would use different approaches.
What are the advantages and disadvantages of each approach? Is there any particular reason why SignalR could not use WCF self-hosting, or Web API could not use HttpListener?
EDIT: I understand that Web API self-hosting provides a more complete stack than SignalR, my question is more about why you would choose a WCF implementation over System.Net.HttpListener when implementing your own self-hosting solution.
Web API self host provides entire HTTP stack so it's much much richer than System.Net.HttpListener.
SignalR uses that to purely open a communication window for its own purposes.
So yeah for now, you need to run them in parallel on different ports.
In the future, with OWIN, you will have everything under one roof.
EDIT: there was actually an issue similar to yours raised on SignalR github, and the answer was pretty much what I just said - https://github.com/SignalR/SignalR/issues/277
Just so we are on the same page, The WCF Self-host that Web API Self host uses, does use HttpListener under the covers. However, I think I may have found a major downside to the WCF Self-host.
I have not confirmed this yet, but it seems that when you use Web API Self Host, the base address you provide is not translated directly into a HttpListener prefix. It seems like WCF translates the base address and wildcards the host.
This means that the WCF self-host will respond to any host on the specified port. This means that you cannot run a Web API Self hosted service side by side with IIS on the same port using a different host name.
This might be the reason that SignalR decided to scrap the WCF Self-Host and use HTTPListener directly.
While you can use the WCF stack to host the services yourself, you may want to consider the "IIS 7.0 Hostable Web Core". It has the benefit of running IIS in your user process. Using this approach, you can have several applications running on the same port, irrespective of the technologies.
If you are interested, you can look at:
Host your own Web Server in your application using IIS 7.0 Hostable Web Core
Creating Hosted Web Core Applications
This all assumes you are running Vista or later...
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.
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 am hosting a ASP.NET web site containing a wcf web service in IIS 7. The web service is exposed using a .svc file that resides inside the web site's virtual directory.
There's section is this document about optimizing the web service performance by removing unnecessary http modules:
http://msdn.microsoft.com/en-us/library/ee377061(v=bts.10).aspx
My question is how can I do that in the web config without affecting the web site? My ASP.NET web site contains authentication stuff and definitely requires some of those modules (eg, FormsAuthentication). Is there a way to enable those modules only for the web site but disable them when the clients access the web service?
Thanks
You should separete your project into two (web and Service).
After that, create a website into IIS and add those two application separatedly, like that:
That way you can handle different configurations for each site, and configure the modules for a especific "project" (like wcf service).