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.
Related
I'm a bit new to WCF, so please bear with me. I have a very simple REST Service written up using .NET 3.5, which is exposed through a asp.net web application through a SVC file. Everything is working as expected.
What I would like to know is if it is possible for me to create a plugin structure in WCF, so that I can have third party developers write up expose their functionality through my service. I'm hoping it's possible to dynamically create my endpoints through code, at the moment everything is in my web.config and service.svc files (as far as exposing the contract).
In the end, what I would like to have an active running service that auto checks for new assemblies (if added to the plugins directory), and would automatically add new endpoints, which could have completely different functionalities. One could be a file transfer plugin, another could be a calculator, etc.
But first I need to know if it's even feasible... currently I'm looking into MEF to see if that might help out, as I'm used to just loading DLLs manually (in Desktop apps).
It is possible to use MEF through WCF, I have worked on a similar project in the past. You could expose functions from the plugin DLL's through MEF assume the implementer of the MEF interface is implimenting a function that starts a new WCF service with it's own end points, then call that function from the main service.
See some sample projects below, although none of them are doing what you are asking it is possible that the MEF plugins could have a service host that's starting their very own service with their own end points.
Creating WCF Service Extensibility through MEF
A sample demonstrating how WCF and MEF play together
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.
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!
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.
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.