Question

We publish a class library that must remain compatible with .NET 2.0. However, we would also like to use this class library internally for WCF-based projects.

Reading e.g. expose-object-from-class-library-using-wcf brings up an approach for using 2.0 class libraries by creating DataContractSurrogate objects to map 2.0 classes. However, our object hierarchy is rich and deep, and this would be tedious and difficult to maintain.

Since we do control the source code, I’m looking for an easier approach.

One thought is to add the DataConract attribute to the source code, and provide an “empty” implementation of DataContractAttribute when the solution is built targeting the 2.0 runtime, and using the System.Runtime.Serialization implementation when the solution is built targeting 3.0 and newer runtimes. This could be accomplished by manually tweaking references between builds.

Is there a better way to implement this approach?

Is there a better approach?

Answer 1

An alternative approach it to add the WCF attributes (DataContractAttribute etc), and build with the .NET 3.0 assemblies.

When you run the application under .NET 2.0, having attributes from an assembly that is not available at runtime won’t normally cause a problem.

(You would get an error if you actually try to access the attributes, but that is unlikely and easy to avoid).