dotnet remoting: I've written a Windows Service, Listens for Data via TCP, Each listener is
spawned in a new Thread creating a new Listener Object.

I have the Interface for the Remoting Server side on the Listener Class
Object (separate Project that Generates a DLL)

The Service Works and I'm running my code form the Listener DLL just fine.
Though when I try to Access my Remoting Interface (HTTP or TCP) the Client
says the connection was refused, like the server side was never Listening.

Once I have the Server side Interface dialed in, shou;d I not be able to see
it listening on the port I defined in a 'netstat -a' command?

I can see my other TCP Port I'm Listening on, but that is using the
TCPClient Object.

I'd rather not have the Remoting Interface to the Listener Object defined at
the Windows Service level as I use the Listener Object in other Apps that
I'd also like to remote into.

Thanks,
Scott<=-

Hi. I'm assuming your Listener class is derived from MarshalByRefOject?
Yes, once the listener is up and running, you should be able to see it
monitoring the port via 'netstate -a'. How are you registering the
channel and class, programatically or with a config file?

It may not be necessary to go through the trouble of spawning threads.
Often, applying the
Synchronization(SynchronizationAttribute.REQUIRES_NEW, False) attribute
to the class is sufficient to prevent collisions. Obviously, this
depends on your application.

I'd start off by making a simple windows application that registers the
channel and listening classes. It's easier to debug. The meat of your
application is the class library added as a second project within the
solution. Later, you can port the class library to a service solution.

If you can get your hands on a copy, 'Programming .Net Components' by
Juval Lowy (O'Reilly Press) is a great reference. Unfortunately, it's
out of print so you may have to content yourself with the sample code
and errata found at http://www.oreilly.com/catalog/pnetcomp/

[quoted text, click to view]