I was doing a little remoting experiment the other day. It consists of a server, host, and client as you would expect. I wanted to demonstrate the use of remoting, so the client has two buttons, one which makes a "hello world" call to the server component, and another button which executes the call to RemotingConfiguration, which you would normally do when the application starts up.
If I push the "hello" button without loading the remoting configuration, the app shows the messages from the client and the server, which clearly demonstrate that they are running in the same process on the same machine. If I load the remoting configuration and then push "hello" you can see that the client and server are running in different processes on the same machine. So far so good.
What's confusing me is this. If I push "hello", then load the remoting configuration, and then push "hello" again the server continues to run in the same process. I can normally answer all my own questions by usenet-diving via Google groups, but I'm not even sure how to phrase my question on this one. It would seem that once the runtime knows how to instantiate a particular class, it will never try to figure it out again. Is it caching this information somehow?
Since I've found this behavior, I feel compelled to try to explain it. It might possibly have some bearing on something else later on. Anyone have any hints?
Read through chapter 4 to see how the client-side DataPortal class interacts with the "server-side" data portal. It caches the remote portal instance and so doesn't adapt to changes during the lifetime of the app.
I know there's another post where someone said they'd removed this caching - which gives this flexibility at (I would guess) a trivial perf cost, so if this is important to you it is a change you may consider.
Actually, I wasn't referring to CSLA directly. I'm talking about the .NET remoting infrastructure itself. I'm building the canonical "Hello world" remoting sample, and thought that this behavior was odd. It would seem that .NET is doing a bit of caching of its own. Once I've instantiated an object locally, all subsequent instances are also local, even if I've loaded a remoting configuration in the meantime that explicitly says that the class in question should be remoted.
Under normal circumstances, you wouldn't change the remoting configuration of an app while it's running, or at least not without recycling the app pool immediately, or in the case of your remoting configuration residing in the web.config, recycling it automatically. Since I'm writing an article for the benefit of my coworkers, however, I know the question will come up. I thought someone around here might know what causes this behavior, and if it can be avoided somehow. At the very least I'd like to include some kind of text pointing this behavior out, but I have no official "name" to call it.
Oh, I see. You should read Ingo Rammer's book on Remoting then - he goes pretty deep into many issues.
To get the dynamic behavior you are after, use Activator.CreateInstance() instead of using the New keyword to create your objects. This not only will switch based on your changing configuration, but also allows you to directly control the URL of the server on a per-call basis.
Copyright (c) Marimer LLC