Is it possible to make the ResponseStatus class in ServiceStack serializable, or to solve this exception in another way: "Type ServiceStack.ResponseStatus is not marked as Serializable"
Im using ServiceStack in an mono embedded system. Works perfect! Now: part of that implementation is that i Serialize the request, and send it over a Socket Connection. I let the receiver DeSerialize it, and build the response, and send it back. However, after expanding ServiceStack Dto's with a ResponseStatus property to receive possible Exceptions in clientSide, i mentioned that the ResponseStatus class in ServiceStack, is not serializable, also mentioned in the exceptions: Type ServiceStack.ResponseStatus is not marked as Serializable.
Many thanks,
Robert
Related
I have a WCF Service; this service has an operation that receives an argument of type Request. This is only the base type, and when calling the operation we actually send a value of type Request_V1 (which inherts from Request), that has the complete implementation of the request I want to send.
When trying to test the service using soapUI, I'm able to create the complex type of type Request_V1 (adding the proper namespace) but for some reason, the service is receiving the value as if it were of Request type.
Reading about ServiceKnowType, I found out here that I need to specify somehow explicitly in the client this inheritance relationship, but I haven't found any info regarding how to do it on soapUI
Has anybody experienced and solved the same issue?
Thanks
You also have to specify the type in the SOAP message.
For example
<Request i:type="d:RequestV1">
...
where i is defined as XML-Instance namespace
On service side, you need to typecast to specific derived type.
operation (Request request){
if(!(request is Request_V1)){
throw Excetion("Unknown type!");
}
var request_v1 = Request as Request_V1;
// use request_v1
}
On SOAP UI side, specify type as below:
<soapenv:Body xmlns:i="http://www.w3.org/2001/XMLSchema-instance">
<ns1:OperationName>
<ns1:request i:type="ns2:Request_V1">
Make sure you have defined ns1 and ns2 before referring to them.
You don't specify the inheritance in the client, rather in the service. SOAPUI shouldn't have a problem with that. Check you have the correct declarations on your data contracts. This might help - Deserialize Abstract Class.
In my WCF service I have implemented a custom encoder which inherits from System.ServiceModel.Channels.MessageEncoder.
In that encoder, I take the raw message and manipulate the received headers in my override of the ReadMessage() method.
During this manipulation, I may sometimes detect something in the header which makes the message invalid, and I want to return a useful exception to the client.
I have tried:
throw new Exception("Some useful message");
And:
throw new FaultException("Some useful message");
They both return an HTTP 400 to the client with no response body.
I can happily throw a FaultException from my actual web service method and this is returned to the client correctly, but at that late stage of the processing I no longer have access to the SOAP headers (unless someone can tell me otherwise).
How can I return a response 500 to the client with a friendly message based on information in the SOAP header?
You can call:
OperationContext.Current.IncomingMessageHeaders
in your service method to inspect the headers there if you wish. A custom MessageEncoder seems to me the wrong beast to be using to do what you describe.
I am moving my WSE3 web services to the WCF. But the client is WSE3 client.
All the Operation Contracts return an instance of the MessageContract classes. This works for 2 operations but somehow fails for one operation of the same service contract. The error is:
The signature or decryption was invalid.
When I look into WCF trace file, I found the following:
The formatter threw an exception while trying to deserialize the message: Error in deserializing body of request message for operation 'MyOperationName'. End element 'Body' from namespace 'http://schemas.xmlsoap.org/soap/envelope/' expected. Found element 'MyOperationName' from namespace 'urn:MyProject:MyModule:2006:04:MyAuthorizationModule'.
My observation is, when I use XmlRoot attribute to decorate response class (instead of using MessageContract attribute), I do not get this exception. However, response object cannot be deserialized. i.e. I can see the XML response in input trace but since the expected XML structure does not match, service call returns null at client side.
The MessageContract class has only one public property (MessageBodyMember) which returns an instance of another class which is decorated with the XmlRoot attribute. This class (which is decorated with xmlRoot) has a property which gives the Collection of objects of some entity class which has XmlElement properties in it.
Which all things I need to check/verify?
I can provide class code snippets if required.
There was no problem with the MessageContract which was used in response. The problem was with the input parameter to the OperationContract.
When I looked at the old WSE3 web service proxy method (WebMethod) and created the OperationContract for it in WCF service, the OparationContract I created did not accept any parameter.
While investigating this issue, I used the svcutil.exe to create .NET classes from the WSDL of the old WSE3 service. When I looked into the specific OperationContract I came to know that I need to create a MessageContract which will be used as request parameter to the OperationContract. So I created a MessageContract without any MessageBodyMember. When I used it, the problem got resolved.
Obviously, if we compare the OperationContract signature with the ASMX WebMethod signature, they dont match since we have introduced input parameter. But this works. I do not know how and why. It would be great if someone explains why it works.
I need to create a WCF service that will emulate some third-party service. That service has very complicated messages and wrappers for them, so I will simplify them in description.
I have WSDL of that service and created proxy class. But here the first problem occurs: all methods in proxy have
[System.ServiceModel.OperationContractAttribute(Action = "", ReplyAction = "*")]
So it is impossible to create WCF service with many methods: each for one method in proxy because every method must have unique Action. I think that third-party service has one method that handles all requests. And I created such method with needed KnownType attributes on RequestTypeBase and ResponceTypeBase. All proxy-class methods have one parameter of type, derived from RequestTypeBase.
And here is the main problem and question: when WCF service tries to deserialize message body, it throws an exception saying that expected elementName is "Process" (the name of my mega-method that processes all requests) but existing elementName is "RequestType1" (the name class with data that must be passed to "Process" method as parameter). So how can I receive such message?? Is there some attribute in WCF to not require the methodName as root of Message body? And I even not understand for what does WCF need that MethodName there if he already knows what method is called? Looks like redundancy with action specification.
Maybe simple MessabeBody example that is successfully processing by WCF, will help to understand what I mean:
<s:Body>
<TestMethod xmlns="someNamespace">
<x>1</x>
<str>param2</str>
</TestMethod>
</s:Body>
You could skip WCF deserialization completely on the service side by using the "universal service contract":
[ServiceContract]
public interface IUniversalRequestResponseContract
{
[OperationContract(Action="*", ReplyAction="*")]
Message ProcessMessage(Message msg);
}
and then handle deserialization yourself working with the Message instance received.
If you are writing a stub emulation of some external service for testing purposes (I'm guessing), that is a good approach anyway because you can control exactly what is sent in the response.
We have a situation where we might want to pass client information on every call we make on a WCF operation. At the response level, we want to have fields to indicate success and an error message.
Is it a good idea to use a Request class and a Response class? I was looking into two operation
OpeationResponseData Operation(OperationRequestData input);
I don't use OpeationRequest because that has issues with wsdl.
I will have base classes that will have the common fields each operation will need.
For example:
OperationResonseData : Response
OperationRquestData : Request
Another option is to use
Request<T> and Response<T>
I was wondering if there were a better way, or if there were some guidelines on this issue...
WCF's base messaging architecture, the Message class, already has support for all of these concepts built in.
For information that is supposed to be passed with each logical operation, you use headers.
For errors you throw FaultException or, if you want to return a custom data structure with your error, you throw FaultException. Being that errors result in faults, the lack of a fault indicates success. If you want to return details about your success then your operation should return a custom data type, otherwise you can just return void.
How this maps to what's sent across the wire depends on what formatting stack you're using (SOAP, REST, etc.). The default stack is SOAP and, being the blueprint for WCF, has a very natural mapping: headers map to SOAP headers and faults map directly to SOAP faults. For REST headers can be mapped as HTTP headers and faults would result in a 500 status with a message.