I am developing a WCF web service and I used the WCF Service Application template to do that.
Does creating a "WCF Service Application" fulfill this requirement?
What are the advantage of creating a WCF Service Library over a WCF Service Application?
A service application includes a website host already setup for you. A service library is a library of services that a host can reference and startup.
If you start with a service library (recommended) you can then choose any host you wish (a windows service, IIS/ASP.NET, or even a console application) and you'd just reference your library from your new host. Choosing a Service Application limits your host to just IIS/ASP.NET (though this might be ok for your purposes, but will limit the protocols you can use).
Edit: Changes in IIS since I wrote this allow for a wider variety of protocols on ASP.NET activated services, so choosing a service application is much less limiting than before.
If all you have is the one project I see only added complexity if you separate for the heck of it. I used a library when I had some particular use cases where I had to host in both a windows service and in IIS.
For IIS you you can move the classes and interfaces to a library but keep your .SVC files in the web project. You must edit the .SVC files to point to the properly qualified classes.
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 know it's been asked, but i want to clear things out, what is the difference between WCF service application and wcf service library, and how can i connect them to other machine?
is Wcf SA need to host on IIS? or is it the SL?
A service application includes a website host already setup for you. A service library is a library of services that a host can reference and startup.
If you start with a service library (recommended) you can then choose any host you wish (a windows service, IIS/ASP.NET, or even a console application) and you'd just reference your library from your new host. Choosing a Service Application limits your host to just IIS/ASP.NET (though this might be ok for your purposes, but will limit the protocols you can use).
If my MVC project is referencing (regular project reference not service reference) a WCF service project, I am not communicating using HTTP right?
I want to make my WCF service exposed to multiple mobile and 3rd party clients via HTTP over the web, but my own application I'd like to use without HTTP due to higher performance.
Is what I'm currently doing achieving this?
If you are using a project reference (i.e. it appears under the "Reference" folder on not the "Service Reference" folder) then you are not using HTTP. You are making a call directly to an assembly/DLL in that case. I generally develop my applications so that there is a Service Layer (sometimes referred to as the Application Layer) that basically mimics the API that the web service presents. This is an assembly that can be referenced directly if I do not want to distribute this service. Then the actual web service is just a thin layer on top of the Service Layer that provides the actual WCF binding and contracts for distributed clients to call.
It depends on how you added it. If you did it via "Add Service Reference" and your app/web.config is littered with WCF client settings then it probably is going over HTTP. You should check the transport and address settings withing your configuration. If you see HTTP then, well, you're using HTTP.
Even if you switch to named pipes there's still an overhead. The fastest transport for local communication is probably the NullTransport sample Roman Kiss developed.
I have found some basic information about hosting a WCF service in a Windows service, but not much. All of my experience thus far with WCF has been in Web projects. I have a few simple questions.
I have a project which creates a windows service application. I have done a right click -> add WCF Service. This creates Service1.cs and IService1.cs.
I'm wondering why no SVC file is created in this scenario? When I add services to Web projects i get an SVC file which I can navigate to and use to consume the service.
Adding the service adds some configurations to the app.config under the services element. I'm seeing a default base address of
http://localhost:8732/Design_Time_Addresses/WindowsServiceName.services/WCFServiceName/
What does this mean? It's sort of an odd looking address. Am I supposed to change it to whatever I want?
Navigating to this address in a browser results in an unable to connect message. Does the windows service itself have to be running to talk to the WCF service?
How do I go about consuming this service from another application without an svc file?
I'm taking a guess on this first one, but I'm thinking the .svc file when hosting in IIS is to tell IIS, "Hey I have a WCF service here, please handle accordingly".
The base address is as it should be and yes you can change it if I'm not mistaken.
You can't hit the WCF service unless the Windows service is running, which is one of the dangers of hosting in a Windows service, because if the service dies somehow your WCF service is offline until you get the Windows service running again.
You consume the service the same way you do any other WCF service, just using that base address to get at it.
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.