I have 2 WCF services now and I want to construct the WCF Service which will use 2 WCF Services(trying to make coarse-grained service).But as you know for making wcf service; create wcf service library and I construct all methods ,write on WCF Service Library.And then I create New Web Site which is WCF Service and I link it to WCF Service Library.
But there exist a problem at that moment; I can't use WCF Service References in the WCF Service Libraries..NET FrameWork can't use wcf service methods in independent WCF Service Library.What is the solution ? The problem is a bit confusing but I think a lot of people are trying to solve this problem ...
You have to move/merge configuration of the referenced WCF services from app.config of your WCF Service Library, to the Web Site's web.config. Everything else should work out of the box.
But there exist a problem at that
moment; I can't use WCF Service
References in the WCF Service
Libraries..NET FrameWork can't use wcf
service methods in independent WCF
Service Library.
?? What do you mean by that?? That doesn't make sense at all. Can you please explain a bit more what you have and what doesn't work??
My "best practice" approach is to have at least two projects for a WCF service:
1) Contracts: all contracts (service, operation, data, fault) go here - only the contracts, nothing else.
2) Service implementation: the actual service code - the code that implements those contracts
Optionally, I might have a third project for hosting the service, not relevant in your case if you have hosting in IIS.
On the client side, I typically also use two projects:
1) ClientProxies which contains all the proxies / service references for others to use
2) Client(s) are the ultimate users of my service - an Winforms App, a WPF app, ASP.NET etc.
I use this approach a lot and I've never had any trouble with not being able to use a service reference or anything, as you say.....
Related
Long time ago, in a world far far away, we used to be able to add web service references to projects simply by right-clicking on the project's References node, and clicking "Add Service Reference". I used to be able to do this with .asmx services, and traditional WCF service.
When I follow different online instructions on "making my WCF RESTful", do I also lose the ability to "Add Service Reference" to those WCF services? Can WCF based REST services be added this way?
If I use Web API 2, can I "Add Service Reference"?
Assume I'm using the latest of everything - VS2015, etc.
When I follow different online instructions on "making my WCF RESTful", do I also lose the ability to "Add Service Reference" to those WCF services? Can WCF based REST services be added this way?
Kind of. You can add a REST MEX endpoint, but I don't think you can use that to generate a service proxy. Though, I think a better question might be, why would you want to? Web API is the best way to go for REST.
If I use Web API 2, can I "Add Service Reference"?
No. Web API doesn't have any type of metadata functionality like WCF.
I have a web site and would like to expose certain functionalities using WCF.
Before deciding which type of WCF project I need to use I wanted to compare the differences between WCF Class library and WCF application. I know this question has been asked many times and answered many times and the answers are usually about different hosting options each one offers but I wanted to try and see the differences, so this is what I tried:
Step 1 - In a same solution, I have created a WCF Service library project and created Client console app project, set the console app as a startup project, referenced the service library project from the client project
and in the client console app I could instantiate the service and can consume the service methods. I didn't even add a service reference to the client project.
Step 2 - In a same solution, I have created a WCF Service application project and created Client console app project, set the console app as a startup project, referenced the service application project from the client project
and in the client console app I could instantiate the service and can consume the service methods. I didn't even add a service reference to the client project.
On both steps after compiling the solutions I was able to copy the client app's exe and the service dll's to a different location and still be able to run the clients.
Based on this little excercie I am confused about the hosting part. It seems wether I use WCF Class library or WCF application type I get the same result.
This is just like using multiple projects in a solution, you reference one from another and use the methods, there must be something I am missing which highlights the differences between the two and highlights the benefits of using WCF, also in the past I remember I had to add a service reference to the clients apps in order to consume the service, why is this not the case here?
Thanks
1) Running a wcf service application allows you to provide communication into a single application, where you have a single instance of a thing you want to provide access to. Maybe this is a game, or a chat room without an external state engine or datastore. This is useful for providing diagnostic information about an application you might have written for example. I used this to provide external control for an industrial robot that I wanted to provide remote control access for.
That is to say, that you write an application, it has a function. You want to expose part of that functionality to remote applications. You do this by adding a WCF endpoint to your existing application, so your application itself is controlling the WCF hosting elements, lifecycle of the endpoint etc.
2) Running a WCF Service is for when you've got an external data store, or your service is stateless. A translation service, lookup service and web page requests fall into this category.
With a service class, you're saying here is this service, this thing that provides a function. It isn't tied to the lifecycle of another application or process and is typically hosted by IIS. IIS manages when the class is loaded and run based on the requests that come into it. These services have no internal persistence and rely on an external datastore, or are, by nature, stateless (think of a postcode lookup, or a calculator service)
It sounds like you're actually adding the projects as references, rather than connecting to them as services. That is to say, that the consuming application is actually loading the service as an assembly (in the same application/ memory space) rather than as a separate application/ service that your application then uses WCF to communicate with.
The WCF Service Application template can be used to create WCF services with a hosting website created within the project
The WCF Service Library template can be used to create WCF services that are hosted by the WCF Service Host, and these can be tested using the WCF service Test Client.
the biggest advantage of using a standalone library (apart from decoupling the logic) is that you can easily migrate your service, i.e. host it in another application or another type of application. E.g., let's say you're hosting your service using IIS - you can easily move your service to a standalone application, etc.
I am designing an Android application which is supposed to connect to a server via WCF web service.
I have a WCF web service written in .NET 4.5 and it is a self-hosted web service. It has SOAP endpoint configuration and it is not a very complex service, however it does include some methods which return DTOs (Classes containing lists, other DTOs and value types).
Now the problem I am facing is that I wish to use some sort of tools to consume the web service definition and generate the proxy classes. I have been successful doing this with the help of Eclipse, but the resulting generated code uses alot of external libraries not available within Android.
Now my question is, what are the preferred tools/methods to consume WCF SOAP web services?
I found that using the following tool gave me the best generated code.
https://code.google.com/p/android-ws-client/
I do recommend this tool to anyone looking for consuming a WCF SOAP web service.
I'm about to start building WCF web service, and i would like to structure solution in such way that is would be:
Easy to develop - i would like so that developers on my team could just get sources, build, and start service, probably best would be to have possibility to start it as console app?
Easy to host this service later in IIS, WAS or windows service.
I was thinking about having this projects:
Shared (for web service interface)
WebService (for actual implementation of web service and svc file)
ConsoleHost (for hosting web service in console app)
Will there be any problems with such approach?
What could be things that i should consider in advance?
Maybe there is better structure?
I would appreciate any insights and links to resources that could help me chose right structure.
p.s. web service itself is simple, but this approach would be reused for more services.
What I tend to do is to place all my interface definitions in one assembly/project, all the service implementations in another assembly project, and the hosting environment, whether it be console, IIS (ie the .svc files) or windows service or whatever, in a separate assembly.
With this information, I say this structure looks fine.
You might also consider creating a separate ServiceModel assembly to store all your custom behavior and WCF. They could then be reused for other projects
I have 2 web services with about 6 web methods in total, most of the code is ofc sitting in assemblies any way, and the web service asmx is really just calling these assembly methods and returning their return type.
How much effort is it to convert the web services from ASMX to WCF?
I pretty much at this stage control the only - non web based clients connecting to the web services, so this is not really a problem, product is in prelaunch.
Check out some of those blog posts and articles on how to do it:
Migrating ASMX to WCF (unfortunately, this link in no longer valid)
Phased Migration From ASMX to WCF
ASMX to WCF migration
and many more - search for "Migration ASMX to WCF" and you'll get a ton of hits
Marc
You should find it extremely simple to convert - especially if your existing asmx web methods are just calling into other classes. Just create a new WCF Service from Visual Studio - that way you still have your existing web services intact. It will automatically create an http end-point for your so you can just dump it straight into IIS (with a little configuration). You will need to describe your DataContract classes but that it trivially simple too.
I did this recently and it was a joy!