When obfuscating, it's important that any Class, Method and Property that is accessible from the outside, either through an assembly reference, or in your case through a Webservice API (which relies on xml serialization under the hood), is not renamed.
Depending on where you apply the obfuscation, either the client will send garbage XML over the wire based on the obfuscated names on its end, causing the server to fail to read the message. Or the client might send the right message, but then the server is expecting all kinds of garbled names, as its classes and properties have been obfuscated.
So, when applying obfuscation, it helps when you have explicit Data Contracts or Data Transfer Objects which are excluded from obfuscation, then map those to your true Domain model, which is private, and is heavily obfuscated.
Or, in case you want the messages to be hard to read on the wire, obfuscate the whole contract, but use the same obfuscated assemblies both on the client and the server. That way they talk the same "nonsense". It's important that the obfuscation tool understands the serialization protocol, so that it won't generate names that are incompatible with XML for example.
So, to answer the end question, What's the use of obfuscation if I have to turn it off for certain classes?, well, it's to protect the real business code, while allowing your interactions to still work over a well-known and well-defined interface.
Thing about it, many banks and hospitals use a standard protocol for serialization, the objects on the wire are well known, but the power of the software isn't in the messages that are transferred from A->B, it's the algorithms and actions that come from sending and receiving these messages. Obfuscation helps you protect this important IP.
From the Dotfuscator FAQ:
You can still take advantage of renaming your non-public types, methods and fields. Dotfuscator obfuscation is very configurable in this respect. Dotfuscator has a convenient "Library" option that automatically prevents all public methods from being renamed. If this doesn't quite fit your application, you can customize the exclusion rules at various levels of granularity. Not to mention control flow obfuscation and string encryption go a long way to protect code without renaming.
It's possible (using attributes) to turn Obfuscation on or off for specific types and attributes as well. Allowing you to keep the property name in tact, but encrypt or obfuscate the internals of the method/property.
