Move ExtensionAttribute into a separate assembly

[GoogleCodeExporter]

At this point where is a lot of libraries which employs an ExtensionAttribute 
definition hack to support .NET, which leads to some well-known problems when 
System.Runtime.CompilerServices.ExtensionAttribute gets redefined in more when 
one assembly. For example, let's consider the following situation I faced 
recently: my project referenced both LinqBridge and Json.NET which has its own 
built-in *internal* copy of LinqBridge (with ExtensionAttribute defined 
*internal* too). This resulted in an "error CS0656: Missing compiler required 
member 'System.Runtime.CompilerServices.ExtensionAttribute..ctor'" and made me 
to recompile Json.NET to reference LinqBridge explicitly.

So, what about moving ExtensionAttribute definition into a completely separate 
assembly, maybe even into a completely separate project? AFAIR, LinqBridge is 
the most notable project which uses this tricky technique, and I hope other 
libraries would eventually switch to that assembly instead of defining their 
own copy of the attribute class, and there would be the only one assembly with 
ExtensionAttribuite for .NET 2.0, providing the "standard" implementation the 
hack.

See also:
http://stackoverflow.com/questions/11025100
http://devhawk.net/2012/06/20/ambiguous-extensionattribute-errors/

Original issue reported on code.google.com by firegura...@gmail.com on 20 Dec 2013 at 3:18

[GoogleCodeExporter]

You should take up this issue with Json.NET. The idea of LINQBridge was to 
provide .NET 3.5-isms for .NET 2.0, which, besides LINQ, includes extension 
methods. In fact, the ExtensionAttribute was internalized in 1.1 and then 
deliberately brought back in 1.2 (see issue #10).

Original comment by azizatif on 20 Dec 2013 at 6:10

• Changed state: WontFix

[GoogleCodeExporter]

> The idea of LINQBridge was to provide .NET 3.5-isms for .NET 2.0, which,
> besides LINQ, includes extension methods.
LINQ is the most known application of extension methods, but not the only one. 
It may
be a good idea to split "providing extension methods for .NET 2.0" and 
"providing 
LINQ to Objects for .NET 2.0", because they are *different* languages features, 
where
the latter is based on the former. There may be other libraries which would 
like to
use extension methods facility which have nothing to do with LinqBridge. If 
they all
declare their own ExtensionAttribute, they may get unusable together with each 
other.

> In fact, the ExtensionAttribute was internalized in 1.1 and then
> deliberately brought back in 1.2 (see  issue #10 ).
I didn't mean it should be internalized. It should be public, but moved away 
from LinqBridge assembly into a separate DLL what would be shipped with it. 
Something
like this:

* LinqBrigde.dll references ExtensionAttribute.dll
* LibraryThatNeedsExtensionMethodsWithLinq.dll references LinqBridge.dll
* LibraryThatNeedsExtensionMethodsButNotLinq.dll references 
ExtensionAttribute.dll

Original comment by firegura...@gmail.com on 20 Dec 2013 at 8:14

[GoogleCodeExporter]

I understand where you're coming from. You can also extend the same argument to 
Action and Func delegates. In any event, this would change the direction with 
which LINQBridge was conceived. Today, it is a project in twilight and the only 
effort made would be, I reckon, towards a showstopper bug. Anything else would 
require considerable resources that are scarce, like volunteered free time. 
That said, LINQBridge is open source and if you are confident it needs to make 
the split, it can be forked (under the same license), changed and re-published 
on NuGet under an alternate Id. 

Original comment by azizatif on 21 Dec 2013 at 6:38

[GoogleCodeExporter]

> You can also extend the same argument to Action and Func delegates.
This would be an overkill. Moreover, multiple Action and Func delegates
may be declared in different namespaces, one for each library which
wants then, and they would be still compatible each with other,
unlike ExtensionAttribute which MUST reside in system namespace.

> LINQBridge is open source and if you are confident it needs to make
> the split, it can be forked (under the same license), changed and
> re-published on NuGet under an alternate Id. 
The key point was to create a common assembly for everyone who wants
to employ extension methods in .NET 2.0, so that assembly must come
from an authoritative source like LinqBridge. Even if I'm going to
fork the project, it will not convince anybody to use that assembly.

> Today, it is a project in twilight
Sad but true. Almost no one cares about .NET 2.0, but some libraries
still try to support it. If there would be a common and widely
acceptable way of using extension methods which will prevent conflicts
between these libraries (caused by ExtensionAttribute), then their
authors would not just terminate that support because they got tired
of bug reports from users of old runtime.

Anyway, thank you for your answers. I'm also sorry for my not very
perfect language.

Original comment by firegura...@gmail.com on 21 Dec 2013 at 8:51