Problems with CAO in .NET remoting.

In his excellent article here, Ingo Rammer states the points why CAO is not a good option for many scenarios.

Excerpt from the article:
CAOs are always bound to the machine on which they have been created. This means that you can't use load balancing or failover clustering for these objects. If on the other hand you'd use SingleCall SAOs, you could use Windows Network Load Balancing (NLB) quite easily to randomly dispatch the method invocations to one out of a number of available servers.
If you are running a single-server application, this doesn't matter too much for you. If however there is the slightest chance that the application has to scale out to a server-side cluster, than CAOs will definitely limit its scalability.
CAOs also affect you on a single server. When running SingleCall SAOs (and when strictly keeping all state information in a database) you can shutdown and restart your server on demand. You could for example upgrade to a newer version or apply some bug fix without having to tell any user to close and restart your client-side application. As soon as you use CAOs however, you instantly lose this feature. If you restart a server in which you host CAOs, the client application will receive exceptions when calling any methods on these objects. CAOs are not restored after restarting your server. Don't use them if you care about restartability or scalability.