I have the following scenario:
There is a complex object that is residing in the standalone class library and some of the object properties have default values.
The object is argument for WCF public method.
I instantiate this object on the client of WCF, assign values to properties and pass it to the WCF public method.
The WCF method on service side accepts it and does whatever.
My problem is that when I instantiate the object on the client property default values are not available for me to use and I have to assign them in code again.
I looked through the past questions on the topic here and did not find anything related to my scenario. I don't really have data contract for the argument although on the client my object gets instantiated not from the class library itself but from the service reference, like WCFServiceReference.MyClass (otherwise WCF method can not accept it as argument).
I would really like to have all those default values to be available on the client.
I would appreciate any assistance.
Thanks!
With your approach -- using the service proxy classes -- the client only gets the properties marked with DataMember. That's why the default values you assign don't appear in the client -- that code is not serialized, so it's not sent with the WCF service.
If you want to share code, you can do it by declaring your DataContract classes in a separate class library. Have the WCF service and the client both reference that library.
Related
I have created a SOAP service.
Now i want to consume it in a c# client application. I added the service using 'Add service reference' and service reference is added to client.
All my service entities are in service. And in current scenerio i can't move them to a common library.
Problem is, my service endpoint is accepting List<Foo> as parameter.
Foo has a method Boo.
In client, when i try to Foo.Boo() i get Cannot resolve symbol Boo error.
Unfortunately only methods on the service itself are exposed via a SOAP web service, methods on objects used as parameters or return values are not. If the method relates to a server-side operation then you could expose it at the service root level taking the instance object as parameter, or if it relates to a client-side operation you could consider adding it as a client-side extension method.
I'm going to be creating a service that needs to make a call to a hosted WCF service halfway around the world. This isn't that big of a deal since the number of transactions that will be made is relatively low. However, I need to pass in an instance of a class that will possibly be defined in the WCF to the necessary WCF function.
So my question is, will that instance of the class exist on my server? Or will I be contacting the host server every time I attempt to set a variable in the object?
EXAMPLE:`
public class Dog
{
public string noise;
public int numLegs;
}
public class doSomething
{
public string makeNoise(Dog x)
{
return x.noise;
}
}
`
All of those are defined in the WCF. So when I create an instance of class Dog locally, will that instance exist on my side or the server hosting the WCF service? If I'm setting 1000 instances of Dog, the latency will definitely build up. Whereas if I DON'T have to contact the server every time I make a change to my instance of Dog, then the only time I have to worry about latency is when I pass it into doSomething.makeNoise.
The host creates a new instance of the service class for each request, if you're using the default per-call instantiation method (which is the recommended way).
So either this is the IIS server which hosting your WCF service that creates an instance of your service class, or it is the ServiceHost instance that you've created inside your own self-hosting setup (a console app, a Windows service etc.).
The service class instance is used to handle your request - execute the appropriate method on the service class, send back any results - and then it's disposed again.
There's also the per-session mode in which case (assuming the binding you've chosen support sessions) your first call will create a service-class instance, and then your subsequent calls will go to the same, already created instance (until timeouts come into play etc.).
And there's also the singleton mode, where you have a single instance of the service class that handles all requests - this is however rather tricky to get right in terms of programming, and "challenged" in terms of scalability and performance
You will need to host your WCF service on a public available server (for example IIS). Successful hosting will provide you with a link for the svc file. Clicking on that will give you a link ending in singleWsdl. You need to copy that link. On your client side, the one that requires a reference to the WCF, you will need to Add Service Reference and pass that link. This will generate proxy code with Client objects that you can use to access your WCF ServiceOperation methods.
At a minimum you should have three projects. A website project to host the actual site. A WCF project to host your services. And finally a shared project, which should contain the classes you are concerned with (the models).
Both the website and wcf projects should reference the shared project, this way they both know how the models look.
The wcf project should return serialzed models as json objects, which I usually do by referencing Newtonsoft.Json.
Your website project should expect this json, and deserialize them, also using Newtonsoft.Json. This is why your class (model) should exist in the shared project, so you can use the same class on both sides of your service call.
I have set up some WCF services that I use to call from javascript to enable ajax calls such as retrieving data in JSON format.
All my services are configured in a web.config etc and I code in c#.
All my services inherit from a BaseService object which has some common properties that are share between all services, for example a logger object, configuration object etc.
My question is, how/where I can set up/assign values to these properties? ie. set up the base service logger property with an instant of a custom logger I created. Apologies if my question is vague but any help would be great.
Properties for Service implementation object cannot be set from client (any kind) because only contract is visible to client. Further, properties such as config and logger are anyway not meant to be part of contract but rather service implementation - so they must get set at server side automatically(i.e. by application infrastructure) for each service object. You have a couple of choices:
Use constructor (either that of BaseService or actual service class) to initialize these properties.
Use IoC/DependencyInjection container (for example, Unity, StructureMap)
This might be very easy, but What I am trying to do here is, I am trying to pass a Customer Object to a Web Service Method. Customer class is on Entity namespace and it is serializable, and I am adding reference to both of my ASP.NET application which calls web service and pass Entity.Customer Object and also in WebService which accepts Enity.Customer Object.
Web Service Method
[WebMethod]
public void AddCustomer(Entity.Customer c)
{}
ASP.NET Applcation
Entity.Customer c = new Entity.Customer;
webservice.AddCustomer(c);
Error
The best overloaded method match for 'TestApplication.localhost.Service1.AddCustomer(TestApplication.localhost.Customer)' has some invalid arguments
I tried changing the web service to accept Object and later cast that object to Customer.Entity, the Application compiles but I was getting XML generation errors.
Are you generating the web service method using the 'Add Web Reference' method from within Visual Studio?
This is a compile-issue right? You application doesn't want to compile? Just go to the definition of the method and make sure you are passing the same customer object as specified in the method definition - usually the generated web service method generates a proxy version of the object and you need to pass that exact same class.
Often the helper methods generated through a service method expect the local generated objects - this is because some elements of the server-side objects aren't serialized, or are handled slightly differently because of the serialization.
Try:
TestApplication.localhost.Customer c = new TestApplication.localhost.Customer();
webservice.AddCustomer(c);
This way you're using the generated objects, with the correctly serialized properties, rather than the original object.
I'll be more specific.
Lets say I have a contract defined for my WCF service. And I have two different WCF clients which reference to this service : "ClientA" and "ClientB".
Now , lets say I want to add an operation (method) to my service which only "ClientB" will use , Lets say I added this operation to the contract and "ClientB" updated its reference and we're all happy. Does clientA also need to update it's reference even though it is not using the new operation?
The client only needs to update his reference, if it's going to use the new Operation contract.
Check out this article: Versioning WCF Contracts
No, WCF web references are generated by the IDE very similarly to references to ASMX or other web services, which means that it breaks things down into a method inventory, such that the client calling code operates as though it were invoking a remote API. Therefore, if only new stuff that does not alter the expected existing functionality is added, then old clients do not need to update.