Find an alternative answer for extension methods introduced in Google.ProtocolBuffers.Serialization assembly

The means used to add extension methods in the 
Google.ProtocolBuffers.Serialization assembly needs to be reconsidered.

*Current Approach*
Currently this is done by adding a faux "System.Core.dll" assembly that can be 
referenced by a 2.0 framework project.  The assembly contains nothing more than 
the required attribute to make this work.  This assembly is never shipped, nor 
copied to an output directory, it just allows the use of extension methods.  
It's a 2.0 "hack" that doesn't break compatibility with using the same assembly 
in 3.5 as adding the attribute to a different assembly would (like LinkBridge 
does).  The other benefit to this approach is that if anyone retargets the 
assembly at 3.5 or later the "real" "System.Core" will be used. 

*Issues*
This means we've got a reference within the assembly to an attribute which 
can't be resolved at execution time. It feels like the kind of thing which 
certainly could cause a problem if anything decides to resolve assembly 
references - which has certainly been known.

*Solutions?*
How about having separate configurations for this - .NET 2.0 and .NET 3.5 - and 
only conditionally compiling the "this"? I feel your pain - it would be so nice 
if extension methods were okay on 2.0, but it just feels like a risk too far 
for a relatively small benefit.

Original issue reported on code.google.com by Grig...@gmail.com on 30 Sep 2011 at 12:48

ebceu4 / protobuf-csharp-port

Find an alternative answer for extension methods introduced in Google.ProtocolBuffers.Serialization assembly #30