WCF, Data Contracts and Enums

With Windows Communication Foundation it is easy to create any kind of services, of course my opinion could be biased because I am a .net (mainly c#) developer, but I really find hard to believe that someone could disagree with such statement.

Of course there is a lot of know-how and trouble for beginners, specially trying to understand that WCF integrates all communication models we know (web, tcp, pipes, message queues) under one uniform paradigm.

But there are some moments where you hit a rock in the path; years ago I stumbled upon the following scenario:

I had a library “common.dll” that I used from both the client and the service. You might think this is not something you would do too often, and many people would say “that a client must not know anything about the service internals”. Well… that’s true, but this is not that case. It is just a situation where a client shares some business logic with the service.

And the problem?

Well, there is no problem with that configuration unless you have an enum in common.dll AND you tag it with the “DataContract” attribute. WCF allows you to do so, but I don’t recommend it. Usually when you have a common set of libraries referenced from both the service and the client, you mark the “reuse types in referenced assemblies” on Visual Studio, right? Look below:

Now, when you do that, and you have tagged an enum as a data contract you will get an error like this:

The solution? Well, do not attribute enums as Data Contracts if you reuse the assemblies. Here you can download a sample project with full source code so you can test this behavior. In order to check both situations, just add/remove the “DataContract” attribute from the MyEnum enum.


Popular posts from this blog

Get-ChildItem vs Dir in PowerShell

The case for a 4 week sprint

NODE.js fs.readFile and the BOM marker