Oh and yes, there's a problem on some operating systems which results in server side remoting channels not immediately closed after the application exits. These problems will result in an exception if you try to restart the server within a period of about 2 to 5 minutes.
If you aren't afraid of some reflection hacks, feel free to email me about a hackish solution which forcibly closes the server-side channel. [I'm not currently at my office PC, else I'd mail it out right now] -Ingo Author of "Advanced .NET Remoting" http://www.dotnetremoting.cc > -----Original Message----- > From: Ingo Rammer [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, April 30, 2002 1:12 AM > To: [EMAIL PROTECTED] > Subject: Re: [DOTNET] Trace question. > > > Hi Nick & Chris, > > well ... I'm an Ingo so I'll try to offer some advice ;-) > > I'd do it like this: > > write a trace lib that checks something like a semaphore [1] > which will be > flagged as soon as the "Tracer GUI" is running. It will then > (only if the > app is listening, i.e. if it's flagged) send remoting > requests to an object > which is published by the tracer gui on localhost via a TCPChannel. > > In the tracer-gui, publish the "receiver"-object via > RemotingServices.Marshal() using a TcpChannel [don't forget > to override > InitializeLifetimeService() to return null]. Maybe even flag > the method > which will receive trace information as [OneWay] to not crash > your client > application during shutdown of the GUI (might else happen if > the client > sends a call exactly at the same instant when you're shutting > down the GUI). > As soon as the app is started, flag the semaphore and release > it when the > app quits. > > This way you can start and stop the tracer GUI independently > from the client > applications. > > (disclaimer: I'm no Chris Sells when it gets that low-level so I don't > really know if a semaphore is the best thing to use in this case ;-)) > > Nick: I really hope you like the book! ;-) > > -Ingo > > Author of "Advanced .NET Remoting" > http://www.dotnetremoting.cc > > > > -----Original Message----- > > From: Nick Wienholt [mailto:[EMAIL PROTECTED]] > > Sent: Tuesday, April 30, 2002 1:01 AM > > To: [EMAIL PROTECTED] > > Subject: Re: [DOTNET] Trace question. > > > > > > Hi Chris, > > > > It should be pretty simple - write a trace listener type that > > takes the > > trace output from the 2 apps and sends it to the console app > > via remoting. > > Handling instantiation of the display app could be a little > > tricky, but > > shouldn't be impossible. The display app could own a mutex, > > and the trace > > listener could start the display app if it could successfully > > acquire the > > mutex. They may be a simpler solution that I am missing - I > > am no Ingo when > > it comes to remoting (they I do own his book :)). > > > > Nick > > > > ----- Original Message ----- > > From: "Chris Jenkin" <[EMAIL PROTECTED]> > > To: <[EMAIL PROTECTED]> > > Sent: Tuesday, April 30, 2002 8:21 AM > > Subject: [DOTNET] Trace question. > > > > > > > I would like to create a trace console for my assemblies. > > Example: I write > > 2 > > > exe's and both use my generic trace class, I would like > to pop up a > > console > > > app that takes a peek at what those other 2 applications > > are doing while > > > they are running. > > > > > > Is this possible? Was I vague enough :) > > > > > > CJ > > > > > > You can read messages from the DOTNET archive, unsubscribe > > from DOTNET, or > > > subscribe to other DevelopMentor lists at > > http://discuss.develop.com. > > > > You can read messages from the DOTNET archive, unsubscribe > > from DOTNET, or > > subscribe to other DevelopMentor lists at > http://discuss.develop.com. > > > > You can read messages from the DOTNET archive, unsubscribe > from DOTNET, or > subscribe to other DevelopMentor lists at http://discuss.develop.com. > You can read messages from the DOTNET archive, unsubscribe from DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com.
