I have some basic questions related to the conversion of Web Service (.asmx) into WCF. We have a running website which use tons of Web Services. These web services use a common dll that has the business logic. We are planning to convert the web services into WCF. Since there many web services, we are planning to convert one at a time. So to begin with there will be one WCF and many web services (asmx) residing on the production server. I have some confusion on how to make the website run with both - WCF and ASMX residing at one place. I would appreciate if someone can answer my queries:
Can I share the same web.config file for both .asmx web service and WCF service? If yes, then what all changes do I need do to to make sure both works at the same time. Adding ServiceModel tag is enough to the existing web.config?
Can I use the web.config to store some configuration parameters that can be shared between the two services - WCF and .asmx? How to call it?
Currently, the common dll (business layer) is using HTTPContext.Current to cache some values. How can I make sure that the code works for both WCF and .asmx calls? What is the best way to convert the code similar to:
xslt = (XslCompiledTransform)HttpContext.Current.Cache[fileName];
string XslFilePath = HttpContext.Current.Server.MapPath(#"~/xsl/" + fileName);
What is the WCF equivalent?
Finally, how can I deploymy WCF changes in production server? Do I just need to copy the service dll and the .svc file?
I know, I have so many questions, and these may look simple to you guys but I am finding hard to figure them out.
1) Can I share the same web.config file for both .asmx web service and
WCF service?
Yes, absolutely - the WCF config lives in the <system.serviceModel> section (mostly), so that's no an issue at all.
2) Can I use the web.config to store some configuration parameters
that can be shared between the two services - WCF and .asmx?
If you create your own custom configuration section or section group - yes, sure. Both the ASMX web service as well as your WCF code can read that custom config section - that's all standard .NET stuff, really (See: How to: Create Custom Configuration Sections Using ConfigurationSection)
3) Currently, the common dll (business layer) is using
HTTPContext.Current to cache some values.
You can turn on the ASP.NET compabitibility mode on your WCF services, and doing so, you a) tie yourself to IIS forever, and b) get access to all the usual HTTP context and stuff like that. See: WCF Services and ASP.NET for more info.
4) Finally, how can I deploy my WCF changes in production server? Do I
just need to copy the service dll and the .svc file?
Copy the service DLL(s), the SVC file, make the config changes - that's it!
Related
I understand what the differences are between a WCF Library and a WCF Service. I typically will build a WCF Library and reference it from a WCF Service. But if I am going to deploy to IIS, why not just deploy the WCF Library and forget about creating the WCF Service. Does it matter which one I deploy?
Answering my own question: From what I have read it doesn't seem to matter much if you deploy a wcf library or a wcf service. If you deploy the library, make sure that you copy the contents of your app config file to the web config file. The wcf service does also provide an svc file, but you only need that if you are using an earlier version of .net framework other than 4.0 or later. If you deploy the service instead of the library, the App config file for the service will pass the content onto the Web.config file when it is deployed. I am pretty sure that these are the only differences. The two people that replied to my question didn't really take the time to read and understand the question. It got marked as a possible duplicate, which clearly it is not.
I've implemented an OData service using ASP.NET WebAPI. I also have some existing web methods in a seperate WCF project which is hosted in an ASP.NET Web Application.
By copying some bits of web config around and copying a couple of code files I've managed to get the WCF methods hosted in the WebAPI project.
Everything seems to be working but I've got a nagging doubt I'm doing something horribly wrong that's going to break when I least expect it.
Is this a good idea?
Depends on your anticipated call volume. The only problem I can think of with this is that incoming WCF requests will be serviced from the same dispatcher thread pool as the OData service. This makes it more likely that you will suffer availability based issues on either endpoint.
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.
Does anyone know how to host a WCF Data Service (or OData) inside IIS7? I'm seeing lots of articles about hosting WCF, but none specific to WCF Data Service.
Thank you very much.
Hosting a WCF Data Service in IIS is actually the default option.
Its a pretty easy 3 step process:
Create a new WebApplication project (or re-use an existing one)
Add a WCF Data Service to the project
Deploy to your IIS server
Step 3 is just the standard process for deploying a WebApplication to IIS.
A WCF Data Service is just a WCF (REST) service, with some additional out-of-the-box functionality added in.
It has a *.svc file and all - it will be hosted very much the same as a "regular" WCF REST service.
So all the articles you see about WCF REST should really apply to WCF Data Services as well - or are you experiencing some difficulties with something specifically??
I am working on a Silverlight application that uses WCF. I need to have my WCF project separate from the ASP.Net application that will host my Silverlight project. I am looking for some guidance on how I should organize my solution and list gotchas other people have experienced during debugging and deployment.
Specifically my questions are
What type of project should I use for the WCF service?(A WCF project, an ASP.NET project with self-hosted WCF services, something else)
What do I need to so to get it so that when I press F5 I can debug both my Silverlight project and my WCF service? Will I need a cross-domain policy just to debug the thing?
Some background info on why I want to do this:
I have legacy web application that I am gradually converting over to a Silverlight application. Because it is a large web application some of its features will be converted to Silverlight before others.
The legacy web application has lots of code in it that is no longer used. Much of the code that is no longer used references 3rd part assemblies. This is why I want to get rid of the old web application. So obviously I don't want to host WCF services that will be kept for future versions in it. That is my reason for wanting to make the WCF project separate.
We're doing the exact same thing.
We're using a WCF project just in case we have to change how it's hosted in the future. (I.E. no longer using IIS)
2.a. You can have a solution with your silverlight projects, and your wcf project. The silverlight project will have a service reference to the wcf service in your solution. That allows you to debug using F5. However, when you go to deploy, you will have to change your app.config service URIs to refer to your production location.
2.b. You will only need a cross-domain policy file if your fully qualified domain names are different for the wcf service and the silverlight app. Ours happen to be different. Here is an excellent article on when to use the policy file: Clicky
Good luck!
Just remember that when you get ready to deploy, if your service is going to be hosted on a different machine than your app, you need to deploy the service first. Then re-configure your service reference, and finally re-compile your Silverlight before deploying. Otherwise, your Silverlight app will look for the service on your local machine instead of where you deploy it.