Whenever we talk about software architecture, we tend to express the preferred ways of doing things by saying "always do x", "do not use y" or "never do z." Given that there is however only one (YOU!) who knows the exact environment and requirements of your current application, there is one thing which we should remember: this is a very specific use of the words "not" and "never" which is not as precice as we might expect.

When we say "never use x", I think we more or less mean: "We have experienced in the past, that the use of X is not necessary in most projects, and usually causes more pain than gain. However: If your project is not like the 95% out there, this functionality might be interesting for you. In this case, you should however spend some time with learning about the exact implications of x and whether or not there are preferrable alternatives."

This is applicable for so many things, including "Never use .NET Remoting as the back-end for your Web services." Most people - myself included - will say that you should never use .NET Remoting with the SoapFormatter as the back-end for your web services. This would only support rpc/encoded SOAP which is excluded by the WS-I Basic Profile. It therefore can not be the basis for interoperable Web services.

Just last week however, I needed to create synchronization capabilities for PocketPCs (via USB or WLAN) in a non-Microsoft environment. No IIS, no SQL Server, no possibility to change this (my client will sell this in a hardware/software combination more or less shrinkwrapped to his customers). Using a Windows Service, which exposes SOAP endpoints via .NET Remoting and the SoapFormatter seemed to be a very good idea in this case. When looking at "the exact implications of X", you will however notice that this would not allow for secure communication. (Authentication and encryption are only supported within IIS.) But you have the possibility to use IP-based VPN communication between the devices and the host machine. Nice? No. But as of today's .NET CompactFramework v 1.0.x, it seems to be the only solution if you can't use IIS on the server side. It's definitely one of these 5% of projects, where the usual recommendations don't work.