In my VS solution, I created a console project, which I'm using as the client, and an empty project for the WCF service.
I then created the WCF service (created my contract and service type and manually constructed the app.config), and added a reference to the WCF service project in the client project.
However, when I called ServiceHost.Open() in the client, the endpoints weren't loading. I eventually determined that I needed to put all of the config information in the Client's app.config, rather than the service's app.config.
I'm not sure if this is normal, or if I'm doing something wrong. In the past, when I've used the WCF project template, this wasn't the case.
Yes, that is normal. Each .NET application (client, service, web site, etc.) has it's own configuration file. To be precise, there's a hierarchy of them, but the bottom end of that hierarchy is unique to the application.
This makes sense if you think about it -- the client would need to contact the service to ask for it's configuration, but it needs to know the endpoint information in order to even try to do that. So yes, the normal process is that client and service both have very similar information in their configuration files.
If you use Visual Studio's built-in tooling to do everything for you, it will automatically create and/or edit the configuration file for your client when you add a Service Reference to the project, copying from the metadata endpoint that WCF exposes for that purpose. Alternatively, you can use the WCF configuration editor tools to edit your client application.
Also, note that nothing actually enforces that your client and server have compatible settings; e.g. you can change the maximum sizes of many buffers/graphs/etc on one side, and not the other, and see some strange behavior. It's up to you to make sure both ends are working with mutually usable settings.
Related
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 am creating a WCF service. At first I had one WCF service library project and one console project which was referencing the this library. And it worked fine when I used "add service reference" in my client project, as long as the service library had a valid App.Config file.
However, now I want to combine the service library and the console host into one console project. After all, the previous console project was pretty simple. But here comes the problem: when I choose "add service reference" and give the endpoint I defined in the App.config file of the new console project, it can't find any service reference. I take it because the service will not be hostedd by wcfsvchost.exe when the add service reference function was on(and I think it makes sense). But I can't think of a way to make it work. So how am I supposed to add a service reference, if my service is one single console-hosted project?
The easiest way for you is to run WCF service, generate a service reference and then combine it into single application. All you will need to do is just change address in your app.config. But be careful with this, as you should change address for client part and not server part of app.config.
This approach, however, will be difficult to maintain in future, when you will decide to change your service data contract and regenerate service reference. You might want to consider the following: wrap service reference into assembly and use assembly instead. This way you will be able to regenerate you service reference whenever needed.
Allow me to explain a little better.
I have a VS2010 Solution, split into 2 projects: a WCF Web Service, and a Class Library that uses the Web Service.
The WCF Web Service is a simple logging service; namespace "LogService", service "LogService", contract "ILogService".
When you use the "Add Service Reference" utility that comes with VS2010 to add a reference to the WCF, into the consuming Class Library project, you will see that the tool correctly adds a reference to a Web Service that can be called through "LogService.LogServiceClient". No problem here.
Now, I have another Solution; this is also split into 2 projects: another WCF Web Service, and a Web Application that uses this new Web Service.
This particular Web Service provides operations performed on a database; namespace "BLService", service "BLService", contract "IBLService".
Using that very same "Add Service Reference" utility in this project, however, adds a reference whose client name is actually "BLService.IBLServiceClient". Please notice there is a "I" prepended to the service client class name. The utility seems to have decided it should use the contract's name, instead of the service's name, to create the service client class.
I don't understand why does the tool behave differently on both Solutions. I've tried checking everything I could from both, and I can't find no significative differences (to my knowledge, at least).
Do you people know why does this happen? What things should I check, and correct, in my Web project (or anywhere else in the solution) so this odd behavior does not happen anymore?
I am developing a wcf service (basicHttpBinding) that should also be consumed by non .net clients (e.g. Java clients). But now I wonder how the client can define his client config file. Or is this file only needed for .net-clients? (I am thinking of configurations like maxReceivedMessageSize or maxItemsInObjectGraph for example).
Each development platform (call it as you want: SOAP stack, Framework, API) has its own way to configure communication. You don't need to bother with it. You just need to expose correct WSDL and client's developer will be responsible for configuring the client application based on his needs.
If you want to extend documentation of your service in WSDL you can use wsdl:documentation. WCF doesn't offer it by default but you can use this technology sample to extend WCF. You can use such documentation for example to describe that service operation can return large amount of data. Another approach to add wsdl:documentation is using WCF Extras.
From the sound of it, the client shouldn't have access to those configuration options. For instance, why should a client to the WCF service be able to specify the maxReceivedMessageSize?
What you probably want to do is define these configuration options on the server-side. If a client makes a call and there is a conflict with one of your options (i.e. the client exceeds maxReceivedMessageSize), you'll want to throw a SoapException back to the client.
If you want to let the client have access to the configuration settings before he or she sends a request, you can always implement a simple web service method that sends back the values.
We currently have a WCF Service which is beginning to reach it's limits performance wise.
We have decided to add another server which will host another instance of the WCF Service.
We have web applications which must communicate with a specific server based on context... e.g. If the web application is dealing with objects from ServiceInstance1 then requests must be directed to ServiceInstance1's EndPoint. If the web application is dealing with objects from ServiceInstance2 then requests must be directed to ServiceInstance2's EndPoint.
I initially thought that a "Intermediate Service" or "Service Manager" could be created, the web application's Service Reference would be updated from the individual Service Instance to the "Intermediate Service" or "Service Manager" and said service would act as a "Broker" to the various Service Instances.
How is this accomplished?
I have currently added a ServiceReference to each service from the Manager however it seems that once a Service is "Referenced" it's types becomes specific to the that of the ServiceReference e.g.
ServiceInstance1's type's are all {ServiceInstance1}.
ServiceInstance2's type's are all {ServiceInstance2}.
I need the types to be the same on the web application end, so this obviously seems like the wrong way to do it.
I would also like that when methods are called on the client generated from referencing the "Intermediate Service" or "Service Manager" that the correct Service Instance is invoked, e.g.
IServiceManager.GetProjectById( {GUID} ) ->
Comes Back to ServiceManager ->
Determines which host has the project and returns the ProjectObject from the correct ServiceInstance.
Where ProjectObject is a Type Defined in ServiceInstance1 and ServiceInstance2.
I think the original service needs to have some of the DLL's pulled out so they can be referenced from the web application side and ServiceManager and a GenericWCF Client can be made.
If I am right hooray for me If someone can point me in the right direction I would appreciate it. If I am wrong can someone please scold me and show me how this is properly done!
The way to solve your problem is to create shared assembly with types used by both services. Reference this assembly on the client consuming your services (manager) and when creating proxies by Add service reference mark Reuse types from referenced assemblies.
What you are building is very simple message router. In WCF 4.0 there is additional support for routing services so you should check those features before developing your own. For WCF 3.5 MSDN magazine contains articles about building message router - part 1, part 2.
Just to Answer this and close it I wound up utilizing the Routing Strategy in .Net 4.0 and custom client class which I modeled after the generated classes from the Proxy.
Before I had the custom client ready I used the auto generated client code and I derived a class from it which allow me to change which service it was connecting to. I determined which service via a property which was made available on all service objects which were serialized.
Long story short this is working 100% as expected including the ServiceManager which can even be bypassed on certain calls which we allow.
We even have the ability to move a project from server to server during run time!
Thanks to everyone who helped! (Especially myself for actually doing the work without being spoon fed)
The easiest way to accomplish what you're trying to do is to stop generating your proxies using the server-hosted URL of the service. Instead, generate your proxies from the *.xsd and *.wsdl locally, and merely change the URL of the endpoint. Alternatively, you can use ChannelFactory<T> to generate proxies on-the-fly, and reference your interface .dll on the client side.
Once you've done that, you can use any common webserver load balancing technique to balance the load between the servers.
Not to put too fine a point on it, but Visual Studio's "Service Reference" is not useful, and should not be used, for services you develop. It's useful only for services developed externally, whose URL and contracts are likely to NEVER change. I personally have never had occasion to use it. For your own services, you should probably be using ChannelFactory<T> or a class based on ClientBase<T> to work out the proxies.