I am new to WCF. I have a small question to ask.
Let's assume IsOneWay=true is set in for one of the OperationContracts in my service contract. Let's say when client calls this method and some exception occurs in the method what happens.
Besically I want to know when this property is set to true how the exception behaves.
Please reply.
Thanks in Advance
Sudhanshu
Depends on the type of error:
if it's an error in your actual service code, then nothing will happen, since the server cannot communicate back anything - the service operation just won't happen. The client channel will be in a faulted state for any future non-one-way call, i.e. unusable for future operations, so you'll have to recreate it to use it again
if it's a security or timeout error, the exception on the client will still happen - those aren't affected by the IsOneWay=true setting
Does that answer your question? If not: what do you need to know?
Related
I am thinking in use some exceptions to from service to client.
I am thinking for example in this case. The client try to insert a register in the database. This register has a value for e filed that exists in the database, and how it has a unique constraint, when I do the savechanges I get an updateException.
I am thinking to use exceptions (faultException) to warn to client of the error, and use a custom class to send to the client the actual data of the register, so in this way the client does not to make other query for the register.
However, in this link, it says that exceptions only should be used in development, no in production, so, without exceptions, how could I do what I want to do?
Perhaps I could use a custom class, that have one list property for each type of entities, and a property bool, that indicates if the operation is right or wrong, other property with an arbitrary code to indicate the type of error... etc. This is a good alternative?
In summary, really is better avoid exceptions in production? how I could communicate to the client errors from the service?
You have 2 options:
Throw exceptions and return WCF faults
Attach error information to you return objects
I personally favour throwing exceptions and returning WCF faults. I dont like the idea of attaching error information to return objects, I feel it violoates object oriented principals. For example a field called 'ErrorCode' has no place on a 'CustomerAddress' object.
I believe that if exceptional circustances arise, then an exception should be thrown. This will also simplfy your code as you wont have to wrap everything in try catch blocks in order to attach error information to your return object. Although you may want to catch unexpected exceptions and then throw a more appropriate exception with a more useful message.
When a method is called on a WCF channel that has been disconnected for some reason, it raises an ObjectDisposedException.
Now is normal operation this should not happen, but if for some reason it did, I would like to be able to handle the exception nicely by showing an error to the user like "An operation failed because the service is not connected".
The problem is I just get a generic disposed exception in my appwide exception handler, so I have no way of determining whether WCF threw it.
to get around this I currently have a wrapper class that simply wraps all service method calls with try/catch and rethrows any ObjectDisposedException's as a custom comms exception that my global handler can deal with. this is a load of boilerplate stuff I could do without though.
Is there any way of determining whether WCF threw the exception?
Cheers
I used to encounter such problem, it seems it's difficult to determine whether the WCF throws exception. You can't use the CommunicationObject.Status for this problem, only when you try to use that channel, it throws exception to tell you that the channel is faulted.
Therefore, I used the way like yours.
I'm not sure if there's a best practice for Response Message in WCF. Could anyone please guide me to right direction please?
I've a BlaResponse Object with following attributes:
1. dateTime
2. sucessfailureMessage.
is there anything else I need to add e.g. number of errors, details of errors. Number of success correlationID etc etc?
Thank you in advance.
Why do you have such attributes. You must have some real requirement for introducing these parameters in your response - for example response grouping both successful and failed operations. If your response is just for single operation you should get rid of that and use exceptions for propagating faults.
WCF has very big support for typed exceptions - FaultContracts. You can create special FaultContract type for any expected exception and throw it with typed FaultException. Client can catch each expected exception separately and handle it.
It is generally considered good practice to hide technical details of errors, or any information that discloses details about the server / architecture from the clients (unless you are debugging of course), as this might compromise your security.
It really depends what you are doing, so I don't think I can say what additional info you might need without more information about your implementation. Even the standard Fault Contract is pretty much just a wrapper for your own custom data.
I am having a wcf method which has got isoneway attribute set to true.Now when i call this service from client ,service is throwing an invalid operation exception back to the client bcos of some business scenario going wrong.My understanding was that it will throw only endpointnotfound exception and timeoutexception.Can someone please explain why thats happening ?
Marking your contract as One-Way means exactly that: messages flow in one way only. Clients won't get an answer or wait for the service to execute at all, so there's no way that your client could possibly get a reply or fault from the service most of the time.
If you want that, then maybe a One-Way service isn't for you and what you really want is a two-way service with an empty reply (i.e. void)
Does the OneWay method return a value or has ref/out parameter? If yes, then that's the reason you are getting InvalidOperationException. This is expected behavior as per MSDN help for OperationContractAttribute.IsOneWay Property (http://msdn.microsoft.com/en-us/library/system.servicemodel.operationcontractattribute.isoneway(v=vs.110).aspx).
Look for remarks section, it has following text:
One-way methods must not return a value or have ref or out parameters; otherwise a System.InvalidOperationException exception is thrown.
PS: I know it's too late to reply to the thread, but for someone like me who stumbles across the post after 3 years or so, it might be useful.
I am maintaing a Windows Forms application using WCF and are using Net.TCP internally. The lifecycle of our connections is GET/USE/CLOSE.
We are having a problem with the application pool crashing with no trace. In looking at netstat, I can see when I come into the application as we have a login service. However, even though we are creating the proxy in a using statement, the connection in netstat does not go away until I physically close the application.
Is this right? Should I be doing something different on the client to force the connection to close?
So if the connection stays open, does it stay open for the duration of the openTimeout setting and then gets torn down?
Microsoft says that you always have to close the connection at the end (see the example at MSDN). I've found the following pattern in this article about WCF disposal handling:
WCFServiceClient c = new WCFServiceClient();
try
{
c.HelloWorld();
}
catch
{
// acknowledge the Faulted state and transition to Closed
c.Abort();
// handle or throw
throw;
}
finally
{
c.Close();
}
The article says you should avoid using since it does not properly close and dispose the WCF service client object, you should do it with a try ... catch ... finally block instead as shown above - this way you're dealing with exceptions (which will abort and then re-throw or handle the exception) and also you take care of finally closing the connection. This is also clearly stated in Microsoft's WCF troubleshooting hints.
Note: The c.Close() in the finally does not do any harm in case of an exception (faulted state), because we call c.Abort() before the exception is re-thrown so the c.Close() does actually nothing in this case. However, if no exception occurs, then c.Close() is actually executed normally and the connection closes as expected.
If your WCF service behaves in a strange way, there are many (other) things which could cause this - here you can find some debugging hints.
First, you should probably not being using your proxy within the context of a using statement even though is does implement IDisposable: http://stevesmithblog.com/blog/idisposable-and-wcf/
That being said, it all depends on how you are utilizing the proxy. Take a look at marc's response here: C#, WCF, When to reuse a client side proxy
Yes, that's the expected behavior: the Net.TCP binding has a protocol-level transport session with your server, something you cannot really control in WCF.
I don't know of any mechanism in WCF to physically tear down that transport-level session - you might be able to do that using low-level TCP calls, but I've never had the need to do anything like that.