Hi Gunter,

1. Check the InnerException for more information.
2. Ensure that the client notifies the server before disconnecting, then regard any RemotingExceptions as an indication of a problem
on the client or connectivity issue and handle accordingly.
3. Use Sockets instead if you need more control.

--
Dave Sexton

[quoted text, click to view]

Hi!

Why does MS make it impossible to handle RemotingExceptions? I use a
IpcChannel for IPC Communication. On the server side I want to know when a
client has been "hard" disconnected (e.g. Process has been killed). Because
I use two way communication, it is no problem.

example:
try{
_clientHandler.Foo(...); // when the client disconnects, a
RemotingException occurs here
} catch (RemotingException ex ){

}

When the client is not still alive, I get an Exception with the Message "The
pipe has been ended". But: How can I query against that specific error? Why
does the RemotingException lack of something like an ErrorNumber (like
SqlException for example) witch tells you what exacly has gone wrong?

What I never will do is:

} catch (RemotingException ex ){

if (ex.Message.IndexOf("pipe has been ended") >= 0) {
...
}

}

I realy think that there is no way to get this information! What to you do
is such cases?


br GP

hello friends

Pls tell me the code where i can make a program in vb.net to send data from
computer to mobile via bluetooth.

Deepanshu

Hello Dave!

[quoted text, click to view]

There is none.

[quoted text, click to view]

This is something I already do. But what in cases when it is not possible
like:

[quoted text, click to view]

This is not an option. I cannot replace an Framework like Remoting by an own
Protocoll just for that minor thing.

When I worte the original posting, I do not realy expect an solution because
there is no "ErrorCode" Property and no InnerException (and no derived
RemotingExceptionClasses witch you may catch). The reason for my posting is
to ask what other developers think about the absense of detailed Error
Information.

In my opinion the Remoting team has just fogotten it. Maybe the internal
project schedule has not allowed to implement proper Error Reporting. I do
not see any technical reasons why there is no Property like "ErrorCode". So
I am looking forward the next .Net Framework Version.


br GP

Hi everyone!

I have submitted this issue to the VS.Net Product Feedback.

https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=175516

Maybe there is a chance to get an "ErrorCode" property if you vote for it!


br GP

Hi Deepanshu,

You should post your question to the group as a new thread instead of as a response to a completely unrelated thread.

Unfortunately, I cannot help you.

--
Dave Sexton

[quoted text, click to view]

Hi Gunter,

Since your using IPCChannel, Sockets don't even enter into the problem so if your server catches a RemotingException and the client
had failed to notify the server before disconnecting it would be safe to assume that the process was stopped, is deadlocked or was
coded incorrectly. Your client could write to the event log to help you determine any failures, but it should be thoroughly tested
to alleviate the latter two possibilities, in which case you'd be left with the reason for the RemotingException being that the
client process was stopped.

The real question is, why do you care how the connection was lost?

When using other Channels, if your client notifies your server before disconnecting and you catch a RemotingException at some point
in server code, then it's safe to assume that there is either a connectivity issue or a problem with the client process. Local
network failure can now be detected using the System.Net.NetworkChange.NetworkAvailabilityChanged event, at least to some extent.

It might not be the most elegant solution, i.e. catching an Exception, but it alleviates the need for code to monitor the health of
the underlying socket connection, which does not provide an event model for connectivity notifications. You could always write this
functionality yourself or as another respondent has mentioned buy a third party framework that does this for you.

--
Dave Sexton

[quoted text, click to view]

[quoted text, click to view]
....

Remoting is seriously flawed. I think that idea was to make it really
simple and it turned out to be - oversimplified. Problem is that losing
connection generally should not be handled with exceptions, as it is
usually normal flow of processing. I would expect any system that
targets distributed environment to have events notifying connection
establishing/tear down and also full connection control (connect,
disconnect).

There is a third party library (genuine channels) that offers this. I
have not used it, so I cannot say anything about stability etc...

Regards,

I know it is not a perfect solution but as a workaround you colud probably use:

Marshal.GetLastWin32Error()

regards,