What about Destructor for Remoting cleaning?

[Guest]

As been said in the discussion ‘Why not destructor
’http://msdn.microsoft.com/newsgroup...harp&mid=203132f5-041f-47c8-8c55-ec35b567dd31

It is, with no doubt, bad to write destructors.

Nevertheless, destructors are needed whenever unmanaged code need to be
handled or freed.

My class is using a Remoting object, does any of this following lines need
to be invoked in the destructor or at the dispose, or maybe I can ignore them
completely assuming the GC will clean them up when it will clean by object.

* RemotingServices.Disconnect(...);
* ChannelServices.UnregisterChannel(...);
* Or any other remoting cleaning that you think is needed.

 

[Richard Blewett [DevelopMentor]]

As been said in the discussion 'Why not destructor?
'http://msdn.microsoft.com/newsgroup...harp&mid=203132f5-041f-47c8-8c55-ec35b567dd31

My class is using a Remoting object, does any of this following lines need
to be invoked in the destructor or at the dispose, or maybe I can ignore
them
completely assuming the GC will clean them up when it will clean by
object.

* RemotingServices.Disconnect(...);

This is called by the server-side remoting process if it has used
RemotingServices.Marshal to hook an object to the end of the server remoting
pipeline. It disconnects this object from the remoting pipeline.

* ChannelServices.UnregisterChannel(...);

The server process (and client process if you are using callbacks) have to
register a channel. You only call this if the process no longer wants to
listen on that channel. If the process is shutting down it will sooon stop
listening on that channel anyway.

* Or any other remoting cleaning that you think is needed.

Remoting is all managed code (as far as the bits that we can touch anyway)
and as such will take care of its own clean up. Also AFAIK nothing in the
remoting infrastructure implements IDisposable so nothing advertises that it
*needs* clean up.

Regards

Richard Blewett - DevelopMentor
http://www.dotnetconsult.co.uk/weblog
http://www.dotnetconsult.co.uk