I have an app that hosts a singleton remote object. If I do a "new" on the
object in the app, and a "new" in a remote client I get two different
objects. One serves all remote clients one serves my application. By
making the object a static member in another class I've worked around the
problem so that the app and remote clients have one copy. But now I have
another problem. A Monitor::Enter( ) call in the app does not prevent a
remote client from entering the same section of code in the same object!
I suspect that there is some subtlety about application contexts is
responsible for this behavior. The main app is a legacy MFC app that needs
..Net remoting to communicate with other processes. It seems like
recompiling with /CLR makes the framework causes the app to automatically
initialize the framework (at least I get that long pause when I start the
app). Is there some other kind of initialization I need to do?
object in the app, and a "new" in a remote client I get two different
objects. One serves all remote clients one serves my application. By
making the object a static member in another class I've worked around the
problem so that the app and remote clients have one copy. But now I have
another problem. A Monitor::Enter( ) call in the app does not prevent a
remote client from entering the same section of code in the same object!
I suspect that there is some subtlety about application contexts is
responsible for this behavior. The main app is a legacy MFC app that needs
..Net remoting to communicate with other processes. It seems like
recompiling with /CLR makes the framework causes the app to automatically
initialize the framework (at least I get that long pause when I start the
app). Is there some other kind of initialization I need to do?