Remoting vs. WCF becomes S/O vs. C/S

A few days ago I talked about my question on using Remoting or WCF. Well, I will now try to summarize the discussion on the RD list. First the arguments in favor of WCF:

1. Web services are click-once friendlier as they require less permissions on client machines (Ingo Rammer)
2. WCF binary messages are smaller and faster than Remoting’s (Clemens Vasters). This one surprised me, but as Clemens is an expert on the topic I tend to believe him (besides, nobody questioned it).
3. Versioning (that is, services versioning) is better dealt with WCF than with Remoting (Ingo Rammer and Steve Swartz)

Now the arguments in favor of Remoting

1. Sharing code between client and server is harder (Rockford Lhotka). Meaning you can't use the *same* assemblies in server and client (as opposed to generating proxies). This is especially relevant in frameworks like CSLA where you share business logic between client and server.

This single point became a whole discussion by itself with several interesting ramifications:

1. The serialization mechanism of web services makes that two pointers to the *same* object in a message becomes two pointers to *two different* objects at the other side. This is relevant for generic frameworks like CSLA.
2. Clemens argued that creating logic bottlenecks like CSLA (and other frameworks) proposes steps on what WCF already do
3. Rocky said that this is done on purpose as the whole idea is to *isolate* the business app from the underlying *ever-changing* technologies (COM+, Remoting, WSE, WCF, ...) Paul Sheriff strongly agreed with this point.
4. Clemens pointed that you can override the default serialization behavior of WCF.
5. After several coming and going messages, and with some help from Christian Weyer and Ingo the mechanism proposed by Clemens became clear, alas it’s not that simple.

In this second part of the discussion, one underlying theme was the fact that WCF default serialization mechanism better serves serviced-oriented scenarios, and there were complains about the fact that *many people want distributed mechanism not for S/O but for client-server scenarios*. It was mentioned that S/O is the way to go, but there were resistance (some of it reasonable, IMHO) as S/O is mostly for *integration* while C/S is still a good solution for intranet situations (as the one I've got in the first place), and here the default WCF serialization doesn't help.

So, how about you? Do you use distributed architectures for S/O, C/S, or both?