Duplicate types generated in WCF proxy

The other day I ran into a problem where I was generating a WCF proxy which without any modification was not compiling. The error message was that some class "C" with property "P" was already defined.

When verifying the generated proxy I noticed that I indeed has 2 versions of a fault contract in my proxy code:
- one decorated with the DataContractSerializer
- and the other one was present to be used by the XmlSerializer

I was getting this problem because I was using a fault contract shared by 2 service operations. The return type of one these operations was of type "Stream". Apparently the "Stream" class is not compliant with the DataContractSerializer and that is why WCF was generating XmlSerializable faut contract. And as my second service operation was DataContractSerializable, WCF was generating a another version of my fault contract which was DataContractSerializable.

Creating an ASMX service with WCF

A few things to know when making your WCF service compatible with ASMX clients:

1. The service must expose an endpoint using the basicHttpBinding.

2. When generating the service proxy, use the Visual Studio "Add Web Service Reference" option instead of the "Add Service Reference" option.

• In fact, the "Add Web Service Reference" uses the wsdl.exe command to generate proxies compatible with ASMX clients. Moreover, WCF will use the XmlSerializer rather than the DataContractSerializer while communicating with these clients.
• The "Add Service Reference" option uses the svcutil.exe command to generate WCF proxies.

3. BasicHttpBinding only supports UserName and Certificate credentials. So for example, you will not be able to use Integrated Windows Authentication to secure for authenticating your WCF service ASMX client.

.Net code comments: To use or not to use ?

There are different types of comments we "often" use in our code, for example, inline comments in methods, XML comments on classes, etc. Are these comments really useful ?

In my opinion, they are and will be useful if:

- they are precise and clear (no need to tell stories in your comments)
- they are updated together with the code they explicit (Revise your code comments)

XML comments enable Visual Studio to provide intellisense on your classes and methods. In addition to this, they can be used to generate techincal documents (e.g. .chm files with all your class and method descriptions).

Most of the time, inline comments won't be necessary provided that you have an intuitive method name with a precise XML comment. Depending on the complexity of the method, you'll be writing some inline comments explaining specific parts of your code. For example, we could do this to explain some complex business logic. Another solution could be to move this logic to another method having its own XML comments.

Once again, there is no one good solution to a problem. The best solution is the one which best suits the problem at hand.

I thank my colleagues for the discussion we had on the above subject.