Dangling references
-
I have an out of proc server, and a buggy beta-ish client. There is always only a single instance of both client and server. Quite frequently, the client crashes before releasing its server reference. The one solution I've come up with for this problem, is to have the server keep track of when the client connects and disconnects (implement my own IConnectionPoints) so that if I get an Advise() call before the required Unadvise() call, I (the server) will decrement my own reference count. Is this as evil as it sounds? I get the feeling this is a kludge solution, and I'm hoping y'all can help me out. :) J
-
I have an out of proc server, and a buggy beta-ish client. There is always only a single instance of both client and server. Quite frequently, the client crashes before releasing its server reference. The one solution I've come up with for this problem, is to have the server keep track of when the client connects and disconnects (implement my own IConnectionPoints) so that if I get an Advise() call before the required Unadvise() call, I (the server) will decrement my own reference count. Is this as evil as it sounds? I get the feeling this is a kludge solution, and I'm hoping y'all can help me out. :) J
Hi, Can you give some snapshots of the code? The out-of-process server - is it a DLL or an EXE? With best regards, Sayan Mukherjee
-
Hi, Can you give some snapshots of the code? The out-of-process server - is it a DLL or an EXE? With best regards, Sayan Mukherjee
Ok, actually, it's not a problem that the client crashes. The client code is just one of our applications. The problem is that WHEN it crashes, it never gets around to Release()ing the interface on the OOP server object. It can't, because it crashes. My question is more about style. Is it OK for the OOP server object to Release() itself if I know that the client will never get around to it? J