Ich habe ein .Net 3.5 Projekt und benutze dort die newtonsoft Libary: www.nuget.org/packages/newtonsoft.json/
Als erstes habe ich die version 50r8 heruntergeladen als zip. Danach habe ich diese entpackt und die dll benutzt, welche im Ordner "BIN/NET35" vorhanden war. Doch beim bauen plötzlich war dann meine ouput dll eine .Net 4.0. Dann habe ich mit dotpeek die netwonsoft dll angeschaut und herausgefunden das es .Net 4.0 ist. Danach habe ich die dll benutzt welche im Ordner "BIN/NET20" ist, doch da kam ein Fehler von wegen Missing Compailer.
Nun ist meine Frage:
Wie kann ich diese Libary benutzten f+r mein .Net 3.5 Projekt, sodass meine output dll auch wirklich eine .Net 3.5 dll ist?


Moderiert von Th69: Topic aus C# - Die Sprache verschoben am Mi 22.01.2014 um 17:55

Die 2.0er Version sollte die richtige sein. Erzähl nochmal was genau du für einen Fehler bekommst.

Hab gerade mal nuget in einem 3.5er Projekt ausgeführt. Ich bekomme eine passende Json.Net Version.

Hallo Ralf,
sehr vielen Dank für deine Antwort. Habe es mit den nuget manager probiert, der fügt die 2.0 version hinzu. Ich probier zu bauen und alles läuft einwandfrei. Keine Ahnung welches Problem das war, wenn ich das manuel hinzugefügt habe. Ich weiß nur das ich lange herumprobiert habe ohne jegliche Erfolge.
Dankeschön nochmal!! Hat mein Problem gelöst!

EDIT:

Hatte so eine Freude das keine Exception aufgetreten sind das ich zu eilig das geschrieben habe.
Funktioniert trotzdem noch nicht, was passiert ist:
Via nuget hat es trotzdem newtonsoft.dll .Net 3.5 hinzugefügt (nach genaueren hinsehen), denn in vs2012 "Properties" zeigte es bei Runtime Version v2.... an. Jedoch mit wenn ich den pfad gefolgt bin war diese in Ordner NET35 drinen. Also habe ich wieder zur .dll .Net 2.0 hingeführt. Doch da kam wieder folgender Fehler wegn Compiler:
Error 4 Missing compiler required member 'System.Runtime.CompilerServices.ExtensionAttribute..ctor'
und
Warning 1 The predefined type 'System.Runtime.CompilerServices.ExtensionAttribute' is defined in multiple assemblies in the global alias; using definition from 'c:\path\packages\Newtonsoft.Json.5.0.8\lib\net20\Newtonsoft.Json.dll'

Zitat:

Via nuget hat es trotzdem newtonsoft.dll .Net 3.5 hinzugefügt (nach genaueren hinsehen), denn in vs2012 "Properties" zeigte es bei Runtime Version v2.... an. Jedoch mit wenn ich den pfad gefolgt bin war diese in Ordner NET35 drinen.

Alle .Net Versionen von 2 bis 3.5 benutzen die 2er Runtime das ist so korrekt. Und zumindest theoretisch sollten die beliebig austauschbar und in einem 3.5er projekt zu benutzen sein.
Wenn NewtonSoft einen speziellen Build für 3.5 hat dann solltest du den aber auch benutzten. Nach deiner Fehlermeldung her haben die in der 2er Version irgendwas schmutziges angestellt und ExtensionAttribute nachdefiniert. ExtensionAttribute ist neu in 3.5 und da man vermutlich Code hat der das braucht wollte man den Teil des Code für blankes 2.0 nicht neuschreiben und hat einfach das ExtensionAttribute mitgeliefert (neu geschrieben aus dem Framework geklaut oder entsprechendes).

Ich konnte hier gerade die Version 2,3,3.5 beliebig austauschen und damit ein Objekt serialisieren. Aber vermutlich habe ich nicht das Feature den Codepfad benutzt der versucht das ExtensionAttribut zu laden.

Das Problem ist ich brauche sehr dringend diese Libary, weil einfach der ganze code schon geschrieben ist. Habe aber auf stackoverflow einen Post über diesen Problem gesehen. Das heißt es haben mehrere dieses Problem, doch mein Problem ist das diese Lösung die dort beschrieben ist nicht funktioniert. Leider habe ich nun zum ersten mal etwas von der ExtensionAttribute gehört, werde mich aber informieren was das genau ist und ob es vielleicht hilft wenn ich die überschreibe?
Sobald ich eine Lösung gefunden habe, werde ich es hier schreiben.

Stackoverflow link, der Post von Herrn 7wp:
stackoverflow.com/qu...n-methods-in-c-sharp

Nein. Wenn es zwei gleiche Klassendefinitionen gibt wird das System streiken. Wenn meine Vermuting stimmt kannst du also auf keinen Fall die 2.0er Version benutzen. Was spricht den gegen das nehmen der ,auch von Nuget eingerichteten, 3.5 Version?

Ich habe ein .Net 3.5 Projekt und mein ouput dort ist eine .dll file. Diese .dll file MUSS .Net 3.5 sein, weil ich diese mit PowerShell(version3) Importieren muss und sollte diese dll höher als 3.5 sein, muss der Benutzer die .config Datei für die Powershell umändern. Welches auf keinen Fall machbar ist und zu riskant in meinem Fall.
Doch meine ouput dll war immer 3.5 bis ich newtonsoft benutz habe. Ich habe die newtonsoft .Net 3.5 benutzt und meine ouput .dll wurde plötzlich .Net 4.0. Welche dann zum Import-Module von Powershell dann ohne der bestimmten config Datei nicht funktioniert.
Dann habe ich mit dotpeek alle Referenzen geprüft und all sind .Net 3.5 oder niederer AUSER die newtonsoft Libary die ist .Net 4.0. Ich habe keine Ahnung warum diese so dargestellt wird und darum (vermute ich) wird dann meine output .dll auch eine .Net 4.0.

Zitat:

Dann habe ich mit dotpeek alle Referenzen geprüft und all sind .Net 3.5 oder niederer AUSER die newtonsoft Libary die ist .Net 4.0.

Wenn du dir im Disassembler die Assembly Attribute angeschaut hast dann hat die AssemblyVersion keinen Bezug zur Runtime.
In der aktuelle Assembly von Newtonsoft steht

[assembly: AssemblyVersion("4.5.0.0")]
[assembly: AssemblyFileVersion("5.0.8.16617")]
[assembly: AssemblyTitle("Json.NET .NET 2.0")]

nichts davon hat aber Bezug darauf gegen welche Runtime die kompiliert wurden. Vermutlich steht in allen Compilaten egal welche du dir anschaust (2,3,3.5,4, 4.5) eh das gleiche. Microsoft hält das bei seien Assemblies synchron das ist aber nur nett und keine zwingende Aussage. Relevant wäre ein TargetFramework Attribut wenn es denn da wäre aber hier nicht vorhanden ist.

Zitat:

Doch meine ouput dll war immer 3.5 bis ich newtonsoft benutz habe. Ich habe die newtonsoft .Net 3.5 benutzt und meine ouput .dll wurde plötzlich .Net 4.0. Welche dann zum Import-Module von Powershell dann ohne der bestimmten config Datei nicht funktioniert.

Wenn in den Projektoption 3.5 steht wird es auch 3.5 sein. Bist du dir sicher das sich auch hier nicht einfach nur die Versionsnummer geändert hat und nicht das TargetFramework? Powershell kenne ich nicht gut genug um zu sagen ob es da irgendeinen Zusammenhang zu den Versionsnummern der Assemblies gibt. Das wäre aber dumm zum Beispiel die Microsoft eigenen Assemblies also die die mit Microsoft beginnen und nicht mit System weil sie sich auf Windowsspezifika beziehen laufen mit Versionnummeren 11,12,13 etc. rum. Wäre blöd wenn die Powershell über die weinen würde.

Sehr vielen Danke für deine Zeit und Hilfe Ralf. Hat mir alles weitergeholfen und habe einiges neues dazugelernt.
Doch wie sich es nun herausstellte war es ein sehr grundlegender Fehler. *peinlich*
Ich habe alles auf einer Remote-Maschine getestet, wo Windows 7 (default PowerShell v2) läuft und dort ging es nie. Aber dadurch das auf meinen Rechner Windows 8 läuft (default PowerShell v3) hat mein Kopf immer gesagt das auf der remote Maschine auch v3 ist. Habe nun einfach von PowerShell v2 auf v3 ein Upgrade durchgeführt und alles geht perfekt!!
Tut mir leid, richtig dummer Fehler von mir.

Kein Problem.
Das du nicht einfach abgetaucht bist als du es bemerkt hast verbuche ich unter respektabel. Das ist leider nicht die Norm.