Hi all i am new to WCF i wanted to know if i use channel factory and if i make any changes in service contract whether the changes will be updated automatically in the client system or not???If the changes are updated automatically how????
No, the channel factory is not updated automatically - you have to update your service reference (if you added it using Visual Studio's Add Service Reference) or you need to re-create the client side proxy from the WSDL/XSD or service URL.
UPDATE: of course, if you're sharing the service and data contracts in an assembly between both the service and the client, then of course you have the client up to date as soon as you have the new service contract DLL in place...
If you want to enable this sharing of service and data contracts, use the following setup:
in your Contracts assembly, have all the service contracts (interfaces) and data contracts (data types)
in your implementation of the service, reference that Contracts assembly and implement the service contract(s)
in your client-side proxy, also reference that shared Contracts assembly, and use ChannelFactory<T> to create a channel factory for the service contract interface T.
With this setup, whenever you make a change to the shared contract assembly, both service implementation and client side proxy will "get" those changes, e.g. they're always up to date and using the same service and data contracts
Related
How can I consume a WCF Data Service without adding a Service Reference.
For a normal WCF service, we use shared contracts and create proxy at runtime to call the service. Is similar concept possible in case of Data Service?
I have been googling for quite some time now but cannot find a definite answer.
I want to consume a wcf service, whose address will be provided at runtime.
The user will enter the address of the wcf service at runtime.
During compilation I have no idea of the service contract or the data contract or the endpoints of the wcf service.
Could someone please let me know how to achieve this requirement ?
This was the original idea behind UDDI. Before making a call, the client would query some central repository and obtain the address, contracts, and bindings of the service endpoint. It would then use this information to assemble and call the channel.
Some ESBs work on this principal - the call to UDDI can also be logged centrally, so an audit is kept of all service calls made within the enterprise.
Microsoft implemented it's own UDDI server which can be integration into SCOM for this purpose.
Im doing a client server application. The server part is implemented with a WCF service. The WCF service exposes data types via service contract. The client is modularized and uses MEF for DI. In the client I have a infrastructure module that references the WCF service. The infrastructure module knows about the WCF data types. My question is , is it possible to let the other modules that references the infrastructure to know about these data types without adding a reference to the WCF service in every module. Is there any way of of exposing the WCF data types
Normally, you have a contract dll. This contract dll contains the service interface and all dependent classes. Your WCF service and any client component will then reference this contract assembly.
As the contract assembly only contains interfaces and POCOs (Plain Old CLR Object, only data, not methods or logic), it can be referenced from virtually anywhere without giving away anything about your infrastructure.
nvoights answere is probably the correct one here however it is also worth mentioning that if you control both server and client then you can if you want put common objects in a dll consumed by both and ignor the WCF generate types. In some senarios that works out better than managing both the server types and the WCF generated equivalent types.
I've this WCF service hosted in a Sharepoint 2010 web application. The WCF has been created using the following factory:
Factory="Microsoft.SharePoint.Client.Services.MultipleBaseAddressWebServiceHostFactory, Microsoft.SharePoint.Client.ServerRuntime, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c"
As you can see this is creating a REST-type service. Because we needed to consume it client-side via jQuery.
Now we also need to access it from a .NET project (WinForms). I've tried adding the Service Reference in VS but it doesn't find anything. I guess that's because it's not a SOAP service right?
So how can I consume it in C# .NET project without breaking the existing jQuery support?
Yes, Add Service Reference does not work for WCF REST services. You have a couple of options here:
Add another endpoint to your service, a SOAP-based one, so that you'll be able to use Add Service Reference on your client. I don't know exactly what the MultipleBaseAddressWebServiceHostFactory does, but you could look how it creates its endpoint(s) and recreate that in another factory - and then add the additional SOAP endpoint
Another alternative is to share the interface definition (the service contract plus any existing data contracts) between the service implementation and the .NET client. Having that interface you can use the WebChannelFactory<T> to create a proxy to the REST service (like you'd have one for a SOAP service).
I was wondering how a client project in Visual Studio could reference a WCF service that doesn't have a mex binding. Whenever I remove the default mex binding in any sample WCF service, the client apps cannot find the service and in the auto-generated comments, it's recommended that in production environment, mex binding should be removed. Then how are the client apps supposed to find the service and reference it?
If you have access to the assemblies which contain the types which define the service contract, operations, and data contracts, then you can just create a proxy on the fly using ChannelFactory. In this instance you would not need to retrieve any service metadata as you already have access to all the information you need to call the service.
For example
// Create service proxy on the fly
var factory = new ChannelFactory<IMyServiceContract>("NameOfMyClientEndpointInConfigFile");
var proxy = factory.CreateChannel();
// Create data contract
var requestDataContract = new MyDataContract();
// Call service operation.
var responseDataContract = proxy.MyServiceOperation(requestDataContract);
It also helps if you have access to the service-side config file so you can copy the endpoint details out of there into your client config.
The mex endpoint is a necessary part of WCF SOAP services. It is what enables client toolkits to pull down the WSDL and auto-generate proxy classes. As you point out, without it, clients have no way to get the information to consume the service. If you want clients to be able to consume and find your service, you should leave it available when your service is in production.