33

I'm getting a strange warning:

The predefined type 'System.Runtime.CompilerServices.ExtensionAttribute' is defined in multiple assemblies in the global alias; using definition from 'c:\Program Files\Reference Assemblies\Microsoft\Framework\v3.5\System.Core.dll'

There is no line number given, so it's hard to figure out what it's on about.

The compiler error code is CS1685

abatishchev
  • 98,240
  • 88
  • 296
  • 433
JoelFan
  • 37,465
  • 35
  • 132
  • 205
  • Related: http://stackoverflow.com/questions/11025100/escape-catch-22-with-extension-attributes-in-net-2-0 – Lilith River Jun 14 '12 at 14:35
  • 1
    The highest-voted answer (not the accepted answer) here provides a general way of solving this warning regardless of which type is causing the problem: http://stackoverflow.com/a/6518336/27846 – pettys Jun 14 '15 at 22:01

6 Answers6

21

Are you using someone's dll (or your own) which had implemented this attribute (with exactly the same name) itself as a means of using some c# 3.0 features on pre .Net 3.5 runtimes? (A common trick)

This is the probable cause. Since it is using the correct one (the MS one in the GAC) this is not a problem though you should hunt down the other and remove it.

ShuggyCoUk
  • 36,004
  • 6
  • 77
  • 101
  • 2
    In my case, it was Newtonsoft.Json.dll version 7.0.1.18503. Oddly, it started producing this warning only when I upgraded my project's TargetFrameworkVersion from v4.5 to v4.5.1 – Jonathan May 27 '15 at 13:59
  • It is common for libraries that target multiple versions of the .NET framework to implement this attribute in their code when they target older .NET frameworks so that they can write extension methods that are used in all versions of their library. As @JaredPar states, it is just to tell the compiler that it is an extension method. For example, this attribute is defined in the .NET 2.0 version of NUnit 3.0 and will give you that warning if you are targeting a newer .NET framework that also includes the attribute. – Rob Prouse Aug 17 '15 at 18:49
  • There is a [nunit test adapter issue](https://github.com/nunit/nunit3-vs-adapter/issues/194) causing this warning too. – Frédéric Oct 14 '16 at 16:49
12

Expanding on ShuggyCoUk's (correct) answer

Truthfully it doesn't matter which version of the attribute is used (GAC, 3rd part, etc ...). All that matters is the C#/VB compiler can find some attribute with the correct name. The attribute serves no functional purpose in code. It exists purely to tell the Compiler "hey, this is an extension method".

You can safely ignore this warning.

JaredPar
  • 733,204
  • 149
  • 1,241
  • 1,454
11

I agree with ShuggyCoUk that the best course of action is to try to remove the offending dll. That may not be possible, though.

Another way to resolve the ambiguity that the compiler is complaining about is to change the Alias of the referenced dll. In your project, in the References folder, if you click on a referenced dll you will see the Aliases property. By default, this is "global", which allows you to do things like "global::SomeNamespace.SomeType". You might simply be able to change the alias to something else.

This fixed a problem I had where I needed to reference Microsoft.Scripting.Core.dll, but it contained some types that conflicted with mscorlib.dll. I changed the Aliases property to be "ThirdParty" instead of "global", and that fixed the warning.

Ron
  • 1,888
  • 20
  • 25
1

I have the same problem.

In my case the problem was the assembly Mono.Cecil.

Migrating from local references to nuget, when i add NHibernate references the package automatically adds this reference.

This reference was removed, and compiled my project again.

Remove it and be happy!!

This image was taken from ILSpy ( https://i.stack.imgur.com/Qyd5o.png )

0

I triggered this error by installing IIS with .NET 3.5 instead of 4.5 by accident.

Fix was to add 4.5 back in in "Add Features ..." in control panel.

Ruskin
  • 5,721
  • 4
  • 45
  • 62
0

The compiler does not know which System.Runtime.CompilerServices.ExtensionAttribute

So it is using the defination from c:\Program Files\Reference Assemblies\Microsoft\Framework\v3.5\System.Core.dll'

A .dll you are using might have the same extenstion.

David Basarab
  • 72,212
  • 42
  • 129
  • 156
  • Sometimes it uses a definition from a third-party library that is marked 'internal', then flags a compile error later when it can't find the type. It's like the conflict resolver ignores the scoping rules. – Lilith River Jun 07 '12 at 12:38