I have been assigned a task to create a WCF service which able to insert or fetch record. I was provided with one DLL, with the help of that I have to create. I am unable to see any method name not it's content. I downloaded one application which decompiled the assembly. Now I am able to see content of it. There are 2 class, one class contain properties (which accesses through get and set method) another class contain method which add record and fetch record.
How to create WCF service from that? I have already created lot of WCF service before that. In that case I have created cs file that in that created class who have properties(get,set) given name to class as datacontract and member as datamember. In service one class which implement interface. In interface just declare method and in interface define that method where I do inert/serach code and consumer application creating instance of service class and calling that method. But how to do in this situation?
You should be able to create a WCF service that wraps the provided DLL.
Create the ServiceContract (interface) with the methods you want.
Create the service that implements the contract, and add a reference to the provided DLL. In the service implementation, you can then call the methods from the provided DLL that you need.
You can also create DataContracts as needed for returning the data (or passing data in).
Essentially, it's exactly the same as the previous WCF services you've created, except that the actual functionality is in a separate assembly (DLL) that you reference, rather than being in the service implementation itself.
Related
I have a WCF service, called A which implements IA. This server uses some classes that are defined in a common class (in a common dll referenced by the A service dll). I have another WCF service, called B which implements IB.
Now, A and B have service reference to each other. This worked fine. But now, when I try to update IB I have a problem. I get a custom tool error failing to generate the code for the service reference. Unchecking the “Reuse types in referenced assemblies” solves this issue, but then I have to cast each type to itself (actually).
I created a separate project, in A solution, that has reference to B service. Now, I am able to add service reference, but I get ambiguous error for all types that are defined in the common dll. Any idea how to solve this issue?
I have a WCF method which takes an argument that is a custom class, say,
void MyWCFMethod(MyCustomClass MethodArgument)
In the above, MyCustomClass has a number of constructor overloads. The service has a reference to the class but not the client. I want to allow the client to use the other overloads but the default constructor is the only one that seems to be allowed. Is there a way to do this?
You can certainly do this, but I think it is important to know why the Data Transfer Objects (DTOs) do not expose logic over the service reference.
The WSDL\XSD metadata that is used in order to generate the client proxy to access the WCF Service only describes the web service by the operations exposed and the datatypes exchanged.
Specifically, XSD only describes the structure of your DTOs and not the logic - that is why there is only the default constructor and public properties/fields available on the client proxy.
So the solution is to put all of your custom classes exchanged between the client and service in a separate shared library. This way both sides of the wire have access to the additional logic (like your parameterized constructors) that you could not obtain via WSDL\XSD.
I guess - no!
As I understand MyCustomClass is data contract and marked by [DataContract] attribute.
So WCF runtime will use DataContractSerializer (by default) to deserialize data from received message to the instance of object.
So where can DataContractSerializer get additional parameters for your specific constructors?
Instance of data contract must have public parameter-less constructor to be instantiated.
But maybe you can write own serializer (but keep in mind that DataContractSerializer cannot be inherited)... and provide additional data to constructor. But if you can get that information somewhere just do it in public parameter-less constructor of your data contract.
So I guess you are doing something wrong. Try to specify what is the goal to pass data in constructor in your case. Maybe your app can use some another solution.
I would like to declare an interface in my Web Service layer and then have the caller create objects of this interface type via proxy and use them to call the service methods.
However, when I decorate the interface with DataContract attribute, I get an error saying this attribute can only be applied to class, struct and enum. I don't think that ServiceContract attribute makes sense, as the interface I am trying to expose is used only for data transfer purposes. I also noticed that when the interface was decorated with ServiceContract, it wasn't displayed in the proxy class created.
What is the best practice to go about this?
You cannot do that. "DataContract" interface cannot be exposed as part of metadata. Also even if you share the interface (in assembly) your clients will not be able to send their implementation back to your service because receiving side needs real type for deserialized instance.
The service contract is used on the interface, that is the name of the services. The data contract is used on the class, the data that you are sending over.
ServiceContract on the interface
OperationContract on the methods
DataContract on Class
DataMember on properties
See: http://msdn.microsoft.com/en-us/magazine/cc163647.aspx
I wrote a couple of simple web methods (as a part of WCF service) that use a couple of (more complex) classes as input/returned parameters. Each web method attributed by [OperationContract], each data class attributed by [DataContract], each data field in the classes attributed by [DataMethod].
On the client side I can call these web methods by adding Service Reference.
All things are fine, but when I create an instance of some of the data classes above on client side, their constructors don't run.
Because it's a little complicate to initialize each instance, every time, I thought there is some way to initialize instances on client side by their own constructors.
Thanks in advance!
Ilan.
Methods exposed on data contracts (including constructors) in your service are only for service applications. Adding service reference will recreated only data structure of your data contract classes because service description is not able to describe logic and logic cannot be serialized.
All classes created with service reference are partial. You can create your own partial class and add your own custom constructors or you can share the assembly with data contracts between your service and client (but it will share all logic added to your data contract classes which is most often what you don't want). Sharing assembly will tightly couple your client and service.
I have a wcf service singleton type, and in the same application an ASP page that uses a service-specific function.
As I can get a reference to the service instance created, not to run twice the manufacturer's service?
My service is published on IIS
I'm guessing you are saying that you have a service that is supposed to be a singleton and because you're in the same AppDomain you can simply create an instance as well.
If you own the service code you can make it a singleton using the Singleton Pattern (there are a number of ways to do that in .NET and Jon Skeet has a list of them here).
Then you need to deal with how does WCF get hold of the instance? In that case there are two options:
Use a ServiceHostFactory and hand the instance to the ServiceHost you create
Implement IInstanceProvider and plumb that in
If you don't control the service class then there is nothing you can do to prevent people creating instances but you can wrap the class in your own singleton and stipulate access must only be via the singleton so it is less likely that someone will create a second instance