ExtensionAttribute definition

Feb 2, 2010 at 11:37 PM

Hello,

Are there currently plans to remove the ExtensionAttribute definition in Json.NET that conflicts with the definition in System.Core, and if not, can I suggest/ask that you do so? The duplicate definition can cause problems compiling, especially if Visual studio uses the definition in Json.NET rather than the system definition. I'm getting the following error on one of my projects:

Error    4    Missing compiler required member 'System.Runtime.CompilerServices.ExtensionAttribute..ctor' 

Removing the reference to Json.NET and re-adding it corrects the problem, as visual studio is forced to use the System.Core version, however, when Visual studio restarts (or you're trying to run the build in CI without a GUI) the problem comes back next time you start VS.

See http://spellcoder.com/blogs/dodyg/archive/2009/01/09/18172.aspx

Any other advice, or anyone know of a way to force it to use System.Core?

 

Thanks,

Nick

 

Coordinator
Feb 3, 2010 at 5:25 AM

Only the .NET 2.0 version of Json.NET has that attribute as far as I can tell, and it is internal. How come you are using the .NET 2.0 version if you are working on a .NET 3.5 project?

Jun 28, 2010 at 9:36 PM
JamesNK wrote:

Only the .NET 2.0 version of Json.NET has that attribute as far as I can tell, and it is internal. How come you are using the .NET 2.0 version if you are working on a .NET 3.5 project?

Can you make the attribute public? Basically what happens is that I have my own project that utilizes this trick. I then add references to the 2.0 version of Json.NET and what happens is that randomly VS2008 will select Json.NET's version which is internal and complains that the .ctor() is not available. Seems like a VS bug though. The attribute is declared internal so it shouldn't be trying to use that type anyway.
Jun 30, 2010 at 8:33 PM

In the Json.NET project properties, change "Target Framework" to ".NET Framework 3.5".  Change the Assembly name to "Newtonsoft.Json.Net35".  Then remove the reference to LinqBridge.dll, and recompile.  Ignore the errors in the test project.  The output will be in the bin\Release folder.

This eliminates the error you described, and as well as the need for LinqBridge.  It seems to work fine -- I don't know why the official release doesn't include this target. (?)

Coordinator
Jun 30, 2010 at 9:40 PM

The default version of Json.NET targets 3.5. Linq and the attribute aren't included in .NET 2.0.

Jul 1, 2010 at 12:08 AM

lazno,

I am trying to use Json.NET compiled against .NET 2.0 - in other words, my application is .NET 2.0 so I want .NET 2.0 version of Json.NET.

That said, the .NET 2.0 binary that ships with the release has the attribute as internal type, which I do not think makes sense.  As in my scenario, my application also has the attribute defined but as public.  But unfortunately, I can't make VS prefer which assembly the type comes from.

I can always recompile the source but it'd be nicer if I didn't have to :)

Jul 1, 2010 at 1:10 AM
JamesNK wrote:

The default version of Json.NET targets 3.5. Linq and the attribute aren't included in .NET 2.0.

 Thanks, I didn't realize that! I had stupidly assumed that Newtonsoft.Json.dll would be the 1.0 framework.  :-P

Coordinator
Jul 1, 2010 at 10:02 AM
jihohan wrote:

That said, the .NET 2.0 binary that ships with the release has the attribute as internal type, which I do not think makes sense.

The Json.NET source code requires it to compile. It uses extension methods and for it to compile in .NET 2.0 it needs the attribute. It is internal because it isn't for other people.

Why VS decides to use an internal class over a public one, I don't know.

Aug 12, 2010 at 1:52 PM

I can compile my .Net 2.0 project using the Newtonsoft.Json.Net20.dll. However, I get the following nasty warning when building:

  • Warning 1 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' 

 

Aug 12, 2010 at 10:19 PM

Yes, this is hugely irritating. Luckily using cci.codeplex.com you can write software that does a post rename of the namespace.

I made a little example of that:

http://cid-058ed096273ef8d4.office.live.com/self.aspx/Offentlig/rename.zip

jsonrenamed contains the json assembly where System namespace has been renamed to Json namespace. That should remove that warning.