Bei der Recherche nicht nur beim 1. gefundenen bleiben 😉
Es gibt ein paar Libs für .NET dazu.
Ok, danke, da schau ich noch mal genauer hin.
Ziehe da auch die Möglichkeit von batch-basiertem Serialisieren in Betracht, sonst passiert wiederum alles im RAM auf einmal.
Ja so mache ich es momentan auch. Lustigerweise wird bei Newtonsoft dann im Hintergrund trotzdem erst das komplette Dokument gebaut und erst am Ende geschrieben.
das hättest du schon zu Beginn schreiben können (dann hätte ich weniger schreiben können)
für den nächsten konkreten Fall gibt es vermutlich wieder andere Möglichkeiten die besser geeignet sind -- daher wozu die allgemeine Abhandlung?
Hätte ich zu Beginn explizit schreiben können. Allerdings fragte ich ja recht allgemein und dachte daher, es wäre selbstklärend! 😉
Ja und die Allgemeine Abhandlung - ich finde das nicht von vorn herein schlecht - im Besten Falle hat man danach ein BIld im Kopf, welche Möglichkeiten für welche Fälle besser/schlechter geeignet sind. Wenn allerdings hier im Forum nur sehr konkrete fragen gewünscht sind, dann muss ich halt das nächste mal konkreter fragen ... 😉
ISerializable hat halt einen anderen Zweck, bestimmte Use Cases. Habs ja oben schon genannt. Kannst ja problemlos auch ohne ISerializable serialisieren.
ISerializable heisst ja nur, dass Du eine manuelle Logik hast - nicht mehr, nicht weniger.
Ja genau. Ich weiß dass ich mit ISerializable eine manuelle Logik implementiere und ich weiß auch, das man ohne serialisieren kann. Ich hatte aber (wenn ich auch mal so die einschlägigen Seiten lese) den Eindruck (nur Eindruck), dass es er weniger/seltener genutzt wird und eher auf andere Wege gesetzt wird ... und frage mich daher warum?
Z.B. ist ja ein Nachteil, dass man mit ISerializable evtl. die Implementierung der Serialisierung ziemlich weit in seine Datenklassen mit reinzieht und in seine "elementaren Datenobjekte" nenn ich es jetzt mal - das finde ich eigentlich nicht so toll. Andererseits hat man das bei anderen Ansätzen eben durch die Attribute.
Aber wie gesagt, das ist eher eine generelle Wir brauchen da jetzt auch nicht vom 100 ins 1000 zu kommen.
Von daher ... vielen Dank auch Dir. Ich habe auf jeden Fall ein paar Anregungen bekommen.
Da ich eine List<int> nicht als komplex bezeichnen würde, werden die konrkreten Typen wohl anders ausschauen, nur wie?
Ich meinte sowohl als auch. In meinem Programm triff das Problem mit komplexen Typen auf - man kann es aber genauso mit einer großen List<int> simulieren und beobachten. Freilich ist int kein komplexer Datentyp, das weiß ich schon ...
Es soll in einen Stream serialisiert werden und später daraus gelesen. Soll nun der Stream von Beginn an gelesen werden (als IEnumerable<T> als Rückgabe) od. eher "random access" im Stream?
Der Stream soll von beginn an gelesen werden. Random Access ist nicht notwendig.
Protobuf wurde schon erwähnt, aber das wurde wegem dem Schema (proto-files) eher abgelehnt. Wenn die (komplexen) Typen doch recht einfach sind, so ist die proto-File ebenfalls recht einfach.
Hast du an andere Formate wie MessagePack gedacht bzw. diese evaluiert?
Kann schon sein, dass Protobuf nicht so verkehrt wäre für meine Lösung - und ja ... eher abgeleht heißt nicht vollständig ausgeschlossen.
MessagePack hab ich angesehen - da bräuchte ich halt auch eine Surrogate-Klasse, da ich sonst die Attribute nicht einfügen kann. Oder kann MessagePack auch ISerializable nutzen und ich habe etwas übersehen?
Nur zur Verdeutlichung / Beispiel: binäres Speichern eines int benötigt 4 byte (per Definition in C# / .NET). Protobuf hat hier eine Optimierung indem bei Werten aus dem Intervall [sbyte.MinValue, sbyte.MaxValue] nur das LSB gespeichert wird, also nur 1 byte benötigt wird. Für [short.MinValue, short.MaxValue], etc. analog.
Klar lässt sich das auch selbst so umsetzen, aber wenn es eine millionenfach genutze Komponente gibt, so ziehe ich diese vor, da mehr Entwicklung dorthin geflossen ist als ich selbst erreichen könnte. Von allfälligen Bugs und deren Fixes ganz zu schweigen.
OK interessant. Pluspunkt für Protobuf.
Also vielen Danke erstmal (euch allen). Es ist auch nicht so, dass ich von euch eine fertige Lösung präsentiert haben möchte, sondern eher Anregungen, Vorschläge was in welchem Falle besser ist und was zu bedenken wäre, Vor- und Nachteile - die habe ich nun auch bekommen. Daher "wehrte" ich mich dagegen, meinen Code zu posten ... 😉
ISerializable habe ich in gut 15 Jahren vielleicht ein oder zwei mal verwenden oder nutzen müssen.
In der Regel kann man mit dem Serializable Attibute und einer ordentlichen Klasse nur für Serialisierung den Standard Fall herstellen.
Das ist mir bewusst. Die Frage war eher - welches ist "better practice", wäre eine der Variante der anderen vorzuziehen?
Ggf. verwalten diese auch nochmal intern eigene Zustände (Member) und erzeugen damit noch einen extra Overhead.
Die werden in meinem Falle doch aber gar nicht mitserialisiert - da es über ISerializable mache und dadruch ja kontrolliere, wasa ich serialisiere...
Je nachdem kannst du also noch Daten einsparen sowohl bei der Serialisierung bzw. Persistierung sowie bei der eigentlichen Datenhaltung im Speicher.
Ebenfalls kann man häufig durch Anpassung der Datentypen noch Speichernutzung vermindern.
Aber wie schon mehrmals gesagt müssten wir die genutzten Klassen kennen.
Die Speichernutzung an sich ist nicht mal das Problem - nur eben wenn ich es mit der Newtonsoft Library serialisiere - da kann ich aber erstmal nicht viel mehr machen, als diese eben nicht zu nutzen. Was später dann im weiteren Fortschritt des Programmes folgt, werde ich sehen - vermutlich muss ich dann nicht die komplette Liste halten sondern kann noch mal Filtern. Daher - es geht auch nicht um die Endlösung, sondern ist erstmal eher ein Zwischenschritt, um den ersten Schritt meines Algorithmus zwischenzuspeichern, um dann auf den Daten weiterarbeiten zu können ohne Schritt 1 jedesmal neu zu berechnen.
Aktuell hast du dich in ISerializable verbissen, weshalb schon viele weitere Ansätze komplett ausgeschlossen werden.
Dadurch nimmst du dir aber gerade mögliche Optionen, was dich selbst in deinen Möglichkeiten unnötig einschränkt.
Ich habe mich nicht darin verbissen, sondern lediglich gefragt, ob es alternativen zu BinaryFormatter bzw. BSON gibt, die diese (bereits implementierte) Schnittstelle nutzen. Wenn es das nicht gibt, dann muss ich eben einen anderen Weg gehen! 😉
Reden wir nun von komplexen Datentypen wie Klassen oder um grundlegende Datentypen wie int/double?
Bisher lesen sich deine Antworten nicht umbedingt klar und eindeutig.
Dadurch ist eine richtige Lösung nicht wirklich lieferbar.
Es handelt sich um komplexe Typen. Eine Klasse, welche weitere Klassen enthält, welche wiederum irgendwan aus primitiven Typen besteht. Das ist aber für das Problem (vollaufender Speicher) das ich habe unerheblich - das kann man auch mit einer großen List von int veranschaulichen - daher die Konfusion vermutlich.
Da du mit einer Liste im Speicher arbeitest, kannst du die Daten eigentlich auch ohne Probleme in einer Sqlite DB speichern.
Mit einem fertigen OR Mapper wie EF Core wäre der Aufwand dann auch recht gering.
Die Daten einladen ist dann auch kein Kunststück.
Aber ohne die Klasse zu kennen, die du wegspeichern willst, ist das für uns alles nur raten und wir können dir keine Hilfe leisten.
Mir ist klar, dass es unendlich viele Möglichkeiten gibt ... das ist ja Teil des Problems. Am liebsten wäre mir eine einfache Serialisierung, die ISerializable nutzt (so wie Newtonsoft.BSON oder eben der BinaryFormatter - was ich ja bereits entsprechend implementiert habe, vlt. aber auch nicht der beste Ansatz ist, zugegeben - aber letztlich handelt es sich erstmal noch um einen Prototyp...daher möchte ich den Refactoringaufwand mögichst gering halten).
Wenn du bestimmte Daten wegen einer externen Klasse ausblenden musst, würde ich schon für die Serialisierung eine eigene Klasse anlegen.
Diese sollte auch nur die Daten enthalten, die du speichern/laden willst.
Da hast du Recht - eshalndelt sich zwar bei diesen Drittanbieter-Klassen auch nur um "kleine" Datenklassen" - das wäre die sauberste Lösung und auch die, wo die Reise am Ende evtl. hingehen soll. Vorerst wäre es mir lieb, wenn ich etwas hätte, was ISerializable nutzt - ohne die Unzulänglichkeiten die BinaryFormatter bzw. in meinem Falle Netonsoft.BSON mit sich bringen.
Mal eine Frage aus Softwaretechnischer Sicht: Ist die Nutzung von ISerializable dann überhautp noch sinnvoll, wenn ich letztlich sowieso Surrogates habe, die ich für die Serializierung nutze oder ist es letztlich an sich schon eher ein Antipattern und man sollte es eher nicht nutzen?
Du sprichst halt sehr pauschal. Wir verstehen unter Deiner pauschalen Ausdrucksweise einfach vielleicht was ganz anderes, als Du vor Dir hast. Es kommt im Endeffekt auch viel auf die Programmierung an, was Speicherplatz und damit RAM kostet (zB Datentypen, Class vs Struct etc...).
Ich will einzig und allein eine große Menge gleichartiger Objekt squenziell wegspeichern. ICh brauche kein Key/Value-Store, da es sich um gleichartige Objekte handelt. Es ist letztlich eine hirachie aus einigen Objekten - es würde zu weit gehen, das hier zu posten und wäre nutzlos. Es geht darum, die Menge zu handeln. Wie gesagt - meine Lösung funktioniert ja - aber eben (momentan) nur mit BinaryFormatter - Newtonsoft.BSON müllt mir den kompletten Ram zu, da es das komplettte Dokument in selbigen, vor dem wegschreiben, zumsammenbastelt (kann im im Code auch sehen).
Man kann den Test auch einfach mit einer sehr großen List<int> machen - da kann man es sehr schön sehen .. BinanryFormatter schreibt die schnell und ohne großartigen Speicherverbrauch weg - Newton.BSON kommt ab einer bestimmten Größe einfach nicht mehr klar. Darum geht es mir!
Kann man machen, ist aber nicht die Hauptaufgabe von ISerializable. ISerializable sagt aus, dass grundlegend eine andere Serialisierung verwendet werden soll, als der Standard.
Eigenschaften ignorieren geht auch einfach mit IgnoreDataMember/NonSerialized.
Ja das stimmt. Mit ISerializable hat man aber mehr Kontrolle. Außerdem waren Objekte von Drittanbietern involviert - wo ich nicht die entsprechenden Attribute zufügen kann - daher dieser (im Prinzip funktionierende) Ansatz... 😉
Dein Problem ist eigentlich nicht das Serialisieren, sondern dass alles im RAM erfolgt. Es gibt genug asynchrone Binary Writer Implementierungen für .NET auf GitHub.
Die Fragen von gfoidl stehen aber immer noch im Raum. Ob das am Ende aber der richtige Weg ist, dass kann Dir hier keiner sagen, weil einfach Infos fehlen.
Jein - ich halte erstmal die List mit den zu serialisierenden Objekten im Ram - korrekt. Diese belegt dann in meinem Falle 3 GB oder so. Mit dem BinaryFormatter kann ich die problemsol wegschreiben (und nachher wieder laden) - aber mit BSON (Newtonsoft impl.) funktioniert das leider nicht, da dann im Ram noch mal das komplette Dokument zusammengebaut wird (und die bereits große Liste noch mal kopiert).
Die nächste Optimierung wäre, nicht in einer Liste zwischenzuspeichern, sondern gleich an den Stream zu schicken. Würde mir im Falle von Newtonsoft.BSON nichts nützen (Erklärung oben)!
Es gibt genug asynchrone Binary Writer Implementierungen für .NET auf GitHub.
Ja stimmt und alle haben irgendwelche Custom Attirbutes - die ich wiederum in die zu serialisierenden Drittklassen nicht einfügen kann. Dann müsste ich mit Surrogates arbeiten und das möchte ich möglichst vermeiden! 😉
Hum... das ist eigentlich die Aufgabe von relationalen Datenbanken....
Aber man kann neben Sqlite auch einfach LiteDB dafür nutzen (Schemalos, ganze Objekte, super performant..).
Datenbanken bieten noch viel mehr, wie Indizierung z.B. - aber im Prinzip hast du ja Recht in dem Punkt. Wenn ich jetzt aber z.B. nur eine lange Liste mit Doubles oder gleichen Objekten (ohne Key/Value) speichern will, wäre es meiner Ansicht nach übertrieben. Ich wüsste ja z.B. wo Element 40402393 steht im Stream und könnte sofort dahinspringen wenn ich wöllte... 😉
Bei der Menge wird es aber schon schwierig diese komplett im Speicher (Liste) zuhalten.
Was sind das den für Objekte?
Ggf. würde sich auch eine relationale Datenbank, wie SQLite an bieten.
Ja das ist es. Am Ende kann ich aber auch jedes generierte Objekt direkt in den Stream schicken, ohne es zwischendurch im Speicher zu halten.
Es sind recht kleine Objekte die entstehen, wenn ich einen Grpah analysiere - dafür recht viele. Relaionale DB ist halt quatsch, weil es immer die selbe Klasse ist, eben nur sehr viele Instanzen, die entstehen udn gespeichert werden wollen (sequenziell) ...
Aus deinen Kommentaren ist leider nicht ersichtlich, was für Daten du nun speichern willst.
Wenn wir von Millionen von Objekten in einer Collection reden, ist ggf. der Ansatz schon falsch.
Wie kommst du darauf? Ich analysiere Daten (in dem Falle einen Graph), die Laufzeit dieser Analyse ist recht lang und es fällt eine Collection mit sehr vielen Objekten an - was sollte man in so einem Fall deiner Meinung nach tun? 😉
Je nachdem was du für Daten hast, kannst du ggf. mit einer NoSQL Datenbank besser fahren als mit einer Custom Lösung.
Ggf. könnte man eine einfache Dokumenten Datenbank mit Json/Bson als Format verwenden.
Oder ggf. auch die Daten in einem Key/Value Store wegspeichern.
Ein paar mehr Details und ggf. ein Beispiel oder Code wären für eine bessere Überlegung nicht verkehrt.
Eigentlich brauch ich keinen Key/Value Store. Es handelt sich um eine Collection der selben Klasse - die will ich einfach nur sequenziell wegspeichern! 😉
JSON ist mir zu groß - BSON würde gehen ... aber der Newtonsoft BsonDataWriter baut halt das gesamte Dokument noch mal im Speicher zusammen vorm wegschreiben - daher ist die Lösung für mich in diesem Falle unbrauchbar. Mit kleinen Collections funktioniert BSON aber eigentlich recht gut und auch die Größe der Ausgabedaten ist zufriedenstellend.
Ebenfalls sei darauf hingewiesen, dass der BinaryFormatter z.B. kein Freund von Änderungen an den Daten ist.
Dieser braucht strikt die gleiche Klassen Instanz beim Deserialisieren wie beim serialisieren verwendet wurde.
Ändert sich die Klasse, sind deine Daten nicht mehr lesbar.
Kann man dann nur über Versionierung der Klassen lösen.
Jein - wie ich schrieb, habe ich ISerializable implementiert und somit die Kontrolle, welche Felder serialisiert werden. Im Prinzip könnte man mit dieser Vorgehensweise auch eine Versionierung implementieren (obleich das mit der Zeit vermutlich hässliche werden würde - schon vor Version 12) ... 😉
Hier solltest du die nächst beste Lösung nehmen.
Ja ... und um diese geht es ja ... daher mein Post! 😉
Und das BinaryFormatter obsolte ist und unsicher schrieb ich doch schon im Eingangspost - daher will ich ja davon weg (im Prinzip funktioniert die Lösung für meine Zwecke) ...
beschreib noch ein paar der Anforderungen
Guter Punkt - vlt. hätte ich das gleich mehr Konkretisieren sollen.
Es geht darum, eine (große) Collection eigener Objekte (die ISErializable implementieren) zu serialisieren. Es geht um einige Millionen dieser Objekte - mit BinaryFormatter komme ich damit auf Dateigrößen von ca. 1GB. Sollte aber auch die 10-Fache menge schaffen können!
Die Daten werden lokal geschrieben, um sie später wiederverwenden zu können (der Algo der die Daten generiert läuft recht lange).
Speicherplatz geht vor performance - es sollte natüclich auch nicht unendlich langsam sein. Mit der Performance wie sie der BinaryFormatter liefert, wäre ich durchaus zufrieden!
"Große Datenmengen" ist immer relativ.
Es geht um eine Liste von mehreren Millionen Objekten. In meinen Testdaten war die Dateigröße (mit Binaryformatter) bei dieser Menge ca. 1 GB. Das ist aber nicht das Ende der Fahnenstange - es könnte sich durchaus noch verzehnfachen (realistisch gesehen). Daher möchte ich binär serialisieren. JSON hatte ich probiert, das war mir etwas zu Groß dann. (ungefähr das 3 Fache wie mit BinaryFormatter.)
Binärserialisierung heisst i.d.R. immer, dass sich alles exakt standardisiert sein muss.
Bson Serializer gibts viele, musst ja nicht auf Newtonsoft setzen.
Das ist mir bekannt, dass das zusätzliche Probleme bringt - daher wäre es schön, eine Library zu haben, die keine komplette Blackbox ist und ISerializable nutzt. Vermutlich zu viel verlangt..
Das Problem bei Bson ist, dass dort z.B. die Feldnamen vollständig mit serialisiert werden müssen.
Dadurch hast du auch einen Overhead, der vermutlich größer sein dürfte.
Das ist mir klar. Ich vergebe daher auch sehr kurze Feldnamen (1 - 2 Buchstaben) - das ist kein Problem da ich ISerializable implementiert habe - danke für den Hinweis dennoch!
Für sowas würde ich, wenn es binär sein muss, auf Protobuf setzen.
Ok danke. Ja das bin ich auch schon drüber gestolpert - war mir eigentlich zu viel Overhead. Mir wäre eigentlich eine Lösung wie Newtonsoft.BSON ganz lieb, welche einfach die ISerializable Schnittstelle nutzt ...
Gut, dass es Dir peinlich ist 😉
Ja ... nächste Woche mache ich Urlaub - das wird Zeit wie es aussieht ... ;D
Hallo,
ich möchte eine große Menge von Daten Binär serializiern. Was würdet ihr vorschlagen. In meinen Datenklassen habe ich ISerializable implementiert. Ich habe bis jetzt eine funktionierende Lösung mit BinaryFormatter - die Serialisierung funktioniert schnell und die erzeugen Dateien sind relativ klein. Auch sehr große Datenmengen sind kein Problem. Allerdings ist BinaryFormatter ja unsicher und soll nicht mehr genutzt werden und das Format ist eine ziemliche Blackbox.
Dann habe ich BSON probiert (Newtonsoft.BSON) - funktioniert im Prinzip auch - ABER: der Newtonsoft Serializer baut das komplette Dokument im Ram zusammen (auch wenn ich die Low-Level-Methoden nutze wie BSonDataWriter.WriteValue() und nicht das Objekt komplett srialisiere). Dadurch funktioniert es zwar bei sehr kleinen Daten gut, bei großen Datenmengen läuft hingegen einfach nur der Speicher voll. Zumindest Newtonsoft.BSON ist damit für mich unbrauchbar.
Daher meine Frage: hat jemand einen Tipp, was man sonst noch nehmen könnte (außer komplett manuelle sertialisierung mittels BinaryWriter)?
Danke schon mal im Voraus,
LG..BS
Wenn man zB versucht statt einer Datei einen Ordner mit dem FileStream zu öffnen, bekommt man auch einen Access Denied Error - einfach kein das Dateisystem so ein Zugriff auf einen Ordner halt nicht zulässt.
Das mir ja jetzt fast schon etwas peinlich - aber es liegt tatsächlich daran. Ich habe ein kleines Testprogramm um verschiedene Serialisierungsmethoden zu testen - und dann irgendwann in der Betriebsblindheit nicht gemerkt, dass ich wirklich beim ändern des Pfades vesehentlich den Dateinamen vergessen hatte und nur den Ordner angegeben hatte! Bisschen hat mich die Access Denied-Meldung dann noch in die Irre geführt und ich tippte auf das Berechtigungsproblem ... xD
Die Anwendung läuft mit dem Rechten des Benutzers der diese startet.
Entsprechend wäre die Frage wie der Code aussieht und ob du sicherstellst, dass alles vorhanden ist (Ordner).
Zeigt am besten mal den Code, dann kann man dies ggf. prüfen.T-Virus
Danke aber es liegt definitiv nicht an nicht vorhandenen Ordern. Dann bekommt man außerdem eine System.IO.DirectoryNotFoundException - ich bekomme allerdings eine System.UnauthorizedAccessException ...
... dass die Anwendung mit den Rechten des Nutzers läuft war auch mein Gedanke - allerdings "sperrt" doch Windows manchmal DAteien die man aus dem Netz geladen hat oder ähnliches und fordert auf zu bestätigen, dass man die Datei wirklich öffenen will - sie könnte ja gefährlich sein. Vlt. ist das in meinem Falle der Fall?
OK danke schon mal. Soweit ist mir ja alles recht klar.
Zur deiner Frage: es handelt sich um eine normale Windows SMB Netzfreigabe, ohne AD. Ich kann mit dem Explorer darauf zugreifen und bearbeite Dokumente die darauf gesichert sind in z.B. mig Word und Excel und sichere Daten darauf. Mein Nutzer hat also definitiv die erforderlichen Rechte zum lesen/schreiben. Wenn ich mit dem Windwos-Explorer bzw. Word/Excel darauf zugreife, springt auch die UAC nicht an (denn mein Nutzer hat alle erforderlichen Rechte)
Also kann es nur so sein dass "nicht zwangsläufig mit den vollen Rechten des Benutzers" die Anwendung läuft. Aber mit welchen Rechten läuft sie dann und wie kann ich die Rechte entsprechend erhöhen, so dass ich darauf zugreifen kann.
BTW: das Phänomen tritt auch bei externen Festplatten auf. Ich kann mit allen Anwendungen auf das Verzeichnis zugreifen, nur meine .Net Applikationen werfen eine AccessDeniedException ...
Hey Leute,
hier eine eigentlich einfach Frage. Ich möchte mit einer .Net-App (Console, getestet mit Framework und .net Core) auf ein Netzlaufwerk oder eine externe Festplatte schreiben, bekomme jedoch immer "Access Denied" in diesem Falle. Nur auf den internen Laufwerken meines Rechners geschiet das nicht. Im Explorer (oder anderen Anwendungen) habe ich die entsprechenden Rechte auf diese Pfade und kann auch schreiben!
Laufen .Net Anwendungen unter einem anderen Nutzer? Oder muss ich irgendwas vor dem Build der App konfigurieren?
Danke schon mal fürs Lesen,
LG...BS
Hallo Leute,
wie die Überschrift schon sagt, habe ich gerade ein (massives) Performance-Problem mit Com-Interop. Die Software die ich schrieb ist mittlerweile mehrere Jahre alt. Sie kommt nicht regelmäßig zum Einsatz - vlt. 1 - 2 mal im Jahr.
Als ich die Software das letzte mal ausführte, war das noch auf dem alten System (Windows 7 und Blomesoftware Version 11) - nun nach dem Update auf Windows 10 und Blome 12 ist es quasi nicht mehr nutzbar. Auf dem alten System hat das Programm für einen Durchlauf ca. 15 min benötigt - nun ist es so langsam, dass es vermutlich min. 1 Woche benötigen würde!
Mir ist klar, dass mir vermutlich keiner eine definitive Lösung aus dem Nähkästchen überreichen kann - aber vlt. einen Ansatzpunkt, wo solche Probleme kommen könnten. Vlt. gibt es irgendwelche Windows(sicherheits)einstellungen oder whatever, wo ich ansetzten könnte. Klar vlt. ist auch einfach das COM bei der neuen Blomeversion irgendwie kaputt - dann könnte ich eh nichts ändern.
Also danke schon im Voraus für den, der hoffentlich einen Tipp für mich hat!
Ansonsten hätte ich noch eine ganz wilde Idee: .NET Standard
Ich hab letztens .NET Standard 2.0 mit .NET Framework 2.0 ans Laufen bekommen. Keine Ahnung wie und warum das ging, aber es ging.
Das könnte evtl. funktionieren. Weiß ja nicht, wie die (das Programm womit ich meine libraries aufrufe) ihren CLR-Wrapper geschrieben haben um das aufzurufen ... aber theoretisch sollte das eigentlich klappen...
Also eine Lösung für die Ewigkeit ist es sicher nicht. Aber für die zu erledigenden Dinge und den Umstand, dass ich eh auf .Net 4.5 festhänge ... nicht so wild und dafür wird es erstmal reichen... 😉
@backspeck42:
Hast Du dir die Lizenz von EXPRESS denn mal durchgelesen?
Es sind aber sowohl hausinterne als auch kommerzielle Produkte möglich.
Tatsächlich. Das hatte ich so gar nicht auf den Schirm. Danke für den Tipp!
Was mir aber gerade noch einfällt:
Es gibt noch JetBrains Rider, das scheint ja gerade sehr an Beliebtheit zu gewinnen und es unterstützt alle aktuellen .NET-Implementierungen.
Doch dafür gibt's keine kostenlose Edition, wenn also der Preis der Grund für die Ablehnung ist, fällt das auch raus.
Also erstmal danke für deine Hilfe!
Jetbrains wäre evtl. eine Alternative gewesen. Naja nicht mal der Preis war der Grund ... z.T. auch andere, politische nenne ich es jetzt mal... (Da gibt es Softwarerahmenverträge die eingehalten werden müssen, dann müssen die Lizensen RDP anbieten, was auch nicht immer der Fall ist und und und) 😉
Wie gesagt - gern VS Code. Aber wenn es mit dem alten .Net-Framework nicht harmoniert, nützt es in dem Falle nicht.
Vermutlichen wird VS Code halt nebenläufig betrieben für neue Projekte in .Net Core oder so - oder ich bekomme es noch mit .Net Framework zum Laufen ... aber erstmal habe ich ja eine funktionierende Lösung und auch noch anderes zu tun... 😃
Von VS gab es bis 2015 auch die Express Versionen.
Die hatten ein andere Lizenz als die Community und zumindest die 2013 und 2015 waren eigentlich genug zur Entwicklung.
Auf jeden fall besser als SharpDevelop
>
Aus lizenztechnischen Gründen kann mein Kunde, für den ich das einrichte, das aber nicht nutzen. Daher ja der Aufwand... 😉
Die Aussage mit den Vermutungen bezog sich auf folgenden Satz:
Mir sind keine Probleme mit .NET Framework bekannt, könnte es mir aber vorstellen, da ...
Das klingt mir halt nach Vermutung. Beweisen muss mir niemand irgendetwas, aber wenn er stichhaltige Informationen hat, bin ich dankbar! Wenn nicht, dann bringen mich diese doch eher vagen Hinweise halt auch nicht weiter. War ja jetzt nicht irgendwie böse gemeint... 😃
Ansonsten entstehen halt manchmal sehr merkwürdige Anforderungen. Habe ich ja teilweise auch schon beschrieben, warum und wieso... 😉
Naja das ist nun keine besonders zielführende Aussage. Wie gesagt, ich nutzte (privat) VS Code für ein .Net Core-Projekt, .Net Framework ging aber nicht "out of the Box". Was ich las war, dass man z.B. kein 32-Bit Debugging mit VS Code machen kann, wenn man .Net-Framework nutzt.
Hier ein paar Zitate von der Microsoft VS Code Seite:
"VS Code only supports a limited set of project types (primarily .NET Core). For full .NET project support, we suggest you use Visual Studio Community."
und auf GitHub:
"The C# extension supports limited full .NET framework debugging. It can only debug 64-bit applications with portable PDBs."
Du kannst mich gern eines besseren belehren - dann aber mit Fakten und nicht mit Vermutungen! 😉
Soweit so gut, nun läuft es ja mit SharpDevelop und ist für meine Zwecke ausreichend!
P.S.
Nein ich kann nicht auf .Net Core gehen, da es sich bei den in der Umgebung zu bearbeitenden Projekten um Extentions für ein anderes Programm handelt, die nun mal mit .Net 4.5 und in 32-Bit kompiliert sein müssen...
Visual Studio Code war mein erster Plan. Das funktionierte mit .Net Core auch ganz gut. .Net Framework habe ich nicht hinbekommen, bzw. bin gleich den anderen Weg gegangen, da ich las, VS Code unterstützt .Net-Framework nur mit Abstrichen (gerade was Debugging angeht).
Hat sich dahingehend was geändert? Gibt es eine einfache Möglichkeit, VS Code zur Zusammenarbeit mit .Net-Framework zu bewegen und auch volles Debugging zu haben? Dann wäre es einen Versuch wert...
Ok Verwirrung meinersteits. Das was fehlte sind nicht Lambdas an sich sondern "Expression-bodied members" - welche ja selbigen Operator nutzen. Diese wurden erst mit C# 6 eingeführt und ich habe C# 5 - wie ursprünglich erwartet.
Also nicht so schlimm - dann nutze ich einfach "normale" Properties und Members, ist nichts was wirklich fehlt...
Ja das ganze Setup brach ab. Auch wenn ich die Redistributibles aus der Installation herausnahm.
Ich habe das Problem jedoch gelöst bekommen - AxImp.exe manuell in ein Verzeichnis kopiert und dann die Environmentvariable "TargetFrameworkSDKToolsDirectory" erstellt, die auf jenes Verzeichnis zeigt. Es ist auch kein Registry-Key nötig.
Nun kann ich meine alten Projekte auch kompilieren und ActiveX Komponente wird auch eingebunden. Eine Sache ist dennoch komisch. Irgendwie häng ich auf ner uralten Sprachversion, die nicht mal Lambdas kennt - obwohl ich ja als .Net-Sdk die Version 4.5.2 nutze. Da müsste der Compiler doch eigentlich schon C# 5.0 können, oder?
Naja vermutlich noch irgendwo ein falsches Toolset eingestellt oder so...
Ja ist genau das was ich brauche. .Net 4.5 und ActiveX. Dafür reicht beim Kunden. Sharpdevelop wird genutzt, da für ihn M$-Lizensen nicht in Frage kommen...
...und ich habe sogar fast eine Lösung: Ich installierte Windows SDK for Windows 7 and .NET4 (das was sharpdevelop vorschlägt) und kopiere dann die AxImp.exe von meinem lokalen Entwicklungsrechner auf das entsprechende System. Soweit so gut - funktioniert auf der VM...aber nicht auf dem Rechner des Kunden. Da bricht das SDK-Setup ab (scheint Visual c++ redestribultibles nicht installieren zu können, da die schon drauf sind?).
ActiveX und SharpDevelop, ist das ein archäologisches Projekt? 8)
Siehe dazu
>
Könnte man sagen - ja.
Hallo Leute,
ich bin gerade dabei, Sharpdevelop als Entwicklungsumgebung einzurichten. Soweit so gut, habe SharpDevelop installiert, .MS-Build-Tools und das Windows SDK und das .Net 4,5 SKD.
Das kompilieren und debuggen von Projekten ohne Referenz zu einem ActiveX-Objekt funktioniert bereits einwandfrei, doch wenn ich versuche ein Projekt mit ActiveX-Referenz zu komplieren, kommt der Fehler, dass axlmp.exe nicht gefunden wurde.
Theoretisch sollte dieses File mit dem Windows SDK kommen und sich dort im Verzeichnis "bin/NETFX 4.0 Tools" befinden - tut es aber nicht.
Komischerweise finde ich dieses File auf meinen anderen Rechnern, auf denen ich Visual Studio verwende ebenfalls nicht - obwohl VS ja auch MSBuild nutzt und letztlich auch auf diese Datei angewiesen sein müsste??
Hat jemand zufällig eine Ahnung oder ist bereits über das Problem gestolpert?
Viele Grüße
bs
Hallo T-Virus,
vielen Dank für deine Antwort. Genau das suchte ich!
Verstehe nur nicht:
When you create a desktop app in Visual Studio that targets the .NET Framework 4.5.1 or a later version, the app uses automatic binding redirection.
Demnach müsste es das doch automatisch machen? Oder ist eine Konsolenanwendung keine Desktopapp? So wie vermutlich bei meiner Winform-App - beide sind ja 4.6.1.
Naja vielen Dank jedenfalls, ich schau mir das mal in Ruhe an...
Hallo Leute,
wünsch euch erstmal nen schönen Sonntag. Wie der Titel des Posts schon sagt, suche ich heute keine Suchtberatung, aber habe ein Problem mit den Projektabhängigkeiten und Dll-Versionen.
Ich Nutze zwei REST-API-Wrapper-Librarys, für 2 Verschiedene API's. Beides sind Pakete von Drittanbietern (mit Nuget dem Projekt zugefügt). Ich nutze diese beiden Wrapper-Librarys aus drei verschiedenen Projekten heraus: 1 Winform-Projekt (.net 4.6.1), eine .net Core Konsolenanwendung und ein "normales" Konsolenprojekt (4.6.1).
Nun habe ich das Problem, dass ich, wenn ich die "normale" Konsolenanwendungstarte, bekomme ich in Library A eine Ausnahme, dass die NewtonSoft.Json.dll in Version 10.0.0.0 nicht geladen werden kann. Das kommt daher, dass Library B ebenfalls Newtonsoft.Json aber in Version 12 verwendet. Kann sie dummerweise auch nicht einfach beide ins Verzeichnis legen - die Namen sind ja gleich.
Wenn ich nun dll ersetze, mit der 10.0.0.0'er Version, kommt die Ausnahme natürlich dann in Library B (NewtonSoft.Json.dll in Version 12.0.0.0 konnte nicht galaden werden).
Eigenartigerweise läuft es in der Winform-Anwendung sowie in der .Net-Core Anwendung problemlos - und das obwohl im bin-Verzeichnis der Winforms Anwendung auch NUR Newtonsoft.Json.dll 12.0.3 liegt. Komischerweise kommt in diesem Falle keine Exception.
Auch unter .NET-Core keine Probleme.
Achja:
Damit es noch etwas komplizierter wird - ich spreche die beiden Libs nicht direkt aus den Projekten an, sondern Verwende sie in einer eigenen Lib, die ich dann wiederum aus den Projekten heraus verwende. Diese Lib ist .Net-Standard 2.0.
Ich weiß klingt konfus - ich bin es auch und steh auch dem Schlauch ... aber vlt. hat ja jemand ne Idee zum Sonntag...
...danke schon mal!
Danke für deine Antwort.
Mit HttpClient tritt die Exception nicht auf - dann nutzte ich jetzt halt den ... sollte man heute ja sowieso und da ich auf .net < 4.5 nicht angwwiesen sein werde... 😃
PS. Visual Studio ist nur ein Editor - keine Runtime.
Wird also nicht an VS liegen.
Ja das ist mir klar. War ungünstig ausgedrück. Ich meinte, dass Problem tritt auf, wenn der Debugger an das Programm angehängt wurde. Also liegt irgendein Fehler vor, der irgendwie in Kombination mit dem Debugger auftritt?
Mal die dotnet --info Ausgaben verglichen?
Das werd ich mal tun!
Bzgl. der Projekteinstellungen: Auf einem anderen Rechner funktioniert es ja einwandfrei. Außerdem kompiliert es ja und das Kompilat macht was es soll...
Hey Leute,
wie schon in der Überschrift steht, bekomme ich eine seltsame PlattformNotSupportedException in meinem Projekt, wenn ich es mit Visual Studio 2017 im Debugger ausführe. Führe ich das kompilierte Programm normal in der Kommandozeile aus, tritt sie nicht auf.
Auch wenn ich das Projekt mittels VS Code (und Omnisharp) Debugge, tritt sie nicht auf. Auf einem anderen Rechner, tritt sie auch im Visual Studio nicht auf. Hier muss irgendetwas an diesem einen VS verstellt sein...
Beim Projekt handelt es sich um ein Kommandozeilenrpogramm, welches mit .Net Core 2.0 übersetzt wurde und welches eine Funktionsbibliothek nutzt, welche .Net Standard 2.0 ist.
Die Exception tritt in der Funktionsbiliothek auf bei:
jsonStr = await webClient.DownloadStringTaskAsync(new Uri("..."));
und tritt darin wiederum bei GetProxy() in "System.Net.Requests.dll" auf!
Hat vlt. irgendjemand eine Idee woran das liegen könnte oder wo ich mal schauen könnte?
Danke schon mal
mfg bs42