default(DateTime) != DateTime.MinValue?
Hallo,
ein Kunde meldete, dass es bei ihm bei einem Webservice Aufruf zu Fehlern komme. Der gemeldete Fehler wird von einem weiteren Webservice geworfen, den der erste Webservice aufruft. Soweit klar, auch warum der Fehler geworfen wird.
Allerdings ist für mich unverständlich, dass es überhaupt dazu kommt.
Der 2. Webservice prüft ein DateTime. Ist dieses DateTime.MinValue, so wirft der Webservice den Fehler.
Im ersten Webservice jedoch wird das Datum ebenfalls geprüft, hier aber auf default(DateTime). Dies sollte ja DateTime.MinValue entsprechen.
Wird im ersten Webservice also festgestellt, dass dieses default(DateTime) ist, wird es auf DateTime.Now gesetzt. Warum aber kann es dann in Webservice 2 DateTime.MinValue sein?
Wissen ist nicht alles. Man muss es auch anwenden können.
PS Fritz!Box API - TR-064 Schnittstelle | PS EventLogManager |
Was sagt denn ein Debugger?
Der Vorteil der Klugheit liegt darin, dass man sich dumm stellen kann - umgekehrt ist das schon schwieriger (K. Tucholsky)
Das Problem mit Internet-Zitaten ist, dass sie oftmals zu unrecht als authentisch angenommen werden. (K. Adenauer)
Kannsch dir nisch sagen. Kann mich am Produktiv System nicht anhängen. 😃
Ich bin die ganze Zeit bei uns am rumtesten, woran es liegen könnte. Der Fehler tritt bei uns aber nicht auf.
Wissen ist nicht alles. Man muss es auch anwenden können.
PS Fritz!Box API - TR-064 Schnittstelle | PS EventLogManager |
Hallo inflames2k,
die Ursache ist tatsächlich komisch, aber bekämpfe einfach das Symptom indem du nicht auf default(DateTime), sondern explizit auf DateTime.MinValue prüfst (wie beim anderen WebService).
Bei Structs wird beim default(Struct) jedes Feld auf seinen default-Wert gesetzt. Wenn die gleichen .net-Versionen verwendet werden sollte es auch immer das Gleiche verhalten haben. Ich weiß jetzt aber nicht ob sich im Laufe von .net an der Implementierung vom DateTime etwas geändert hat und dadurch unterschiedliche Werte für default(DateTime) entstehen. Das glaube ich aber nicht.
Interessant wäre tatsächlich ein Tracing o.ä. Vllt. stammt der andere Wert vom DateTime, der zum Vergleichen vewrendet wird, von einer anderen Stelle die in der Überlegung nicht berücksichtigt wurde.
mfG Gü
Stellt fachliche Fragen bitte im Forum, damit von den Antworten alle profitieren. Daher beantworte ich solche Fragen nicht per PM.
"Alle sagten, das geht nicht! Dann kam einer, der wusste das nicht - und hat's gemacht!"
Naja, das Symptom werde ich erst bekämpfen, wenn ich mir ganz sicher bin, dass ich die Ursache nicht direkt beheben kann oder dass die Ursache ein Unterschied in default(DateTime) ist.
Nachträgliches Tracing ist auch doof. Ich kann unsere Kunden schlecht als Anwendungstester nutzen.
Der Wert des DateTimes stammt in beiden Fällen von der selben Stelle. Ein Handscanner ruft Webservice 1 auf. Der Verarbeitet die Daten und gibt sie 1 zu 1 an den 2. Webservice weiter. Der 2. Webservice dient zur Kommunikation mit einer Maschine. Daher ist es dort so wichtig, dass das Datum auch gesetzt ist.
Lässt sich irgendwo im Netz nachvollziehen, welchen default(DateTime) in den einzelnen .NET Versionen hat? Ich kann über die super tolle Suchmaschine nix finden.
Wissen ist nicht alles. Man muss es auch anwenden können.
PS Fritz!Box API - TR-064 Schnittstelle | PS EventLogManager |
Hallo inflames2k,
bei .net 2.0 bis .net 4.0 hat sich da nix geändert.
mfG Gü
Stellt fachliche Fragen bitte im Forum, damit von den Antworten alle profitieren. Daher beantworte ich solche Fragen nicht per PM.
"Alle sagten, das geht nicht! Dann kam einer, der wusste das nicht - und hat's gemacht!"
Dann kanns ja daran nicht liegen. 🤔
Wird mir wohl nichts anderes übrig bleiben, als zu versuchen es zu rekonstruieren.
Wissen ist nicht alles. Man muss es auch anwenden können.
PS Fritz!Box API - TR-064 Schnittstelle | PS EventLogManager |
Ich würde ganz stark darauf tippen, das Die Information vom ersten zum zweiten Webservice auf der strecke bleibt, und deshalb DateTime.Min als default stehen bleibt.
Glaskugel rauskram.. Ihr hab nicht zufällig gerade von Propertys {get;set;} nach Propertys mit backing fields umgestellt? oder andersrum? Ansonsten würde ich mal den Fiddler rauskramen und beim kunden den Netzwerktraffic zwischen den beiden Webservices mittracen. Auch schön ist es, wenn die Reference auf den Service alt ist.. oder oder oder..
Ich würde ganz stark darauf tippen, das Die Information vom ersten zum zweiten Webservice auf der strecke bleibt, und deshalb DateTime.Min als default stehen bleibt.
Gut denkbar und das wahrscheinlichste.
Glaskugel rauskram.. Ihr hab nicht zufällig gerade von Propertys {get;set;} nach Propertys mit backing fields umgestellt? oder andersrum?
Nein haben wir nicht.
Ansonsten würde ich mal den Fiddler rauskramen und beim kunden den Netzwerktraffic zwischen den beiden Webservices mittracen.
Das ist leider undenkbar. Die IT-Sicherheit des Konzerns würde da sehr schnell mit erhobenem Finger auf mich zukommen. 😉
Auch schön ist es, wenn die Reference auf den Service alt ist.. oder oder oder..
Ich habe bei den Servicereferenzen eigentlich immer die Erfahrung gemacht, dass solang sich die Property des Objektes nicht ändert (im Namen oder Typ etc.) dass dies nicht stört, solang nur neue Properties hinzukommen.
Der 2. Service hat sich allerdings in den Methoden in der letzten Zeit geändert. (Nach außen jedoch immernoch die gleiche Schnittstelle und eine Property mehr beim besagten Objekt.)
Ein Fehlverhalten hierdurch wäre bei uns jedoch nachvollziehbar, da wir selbst Testsysteme haben auf denen die aktuellen Versionen liegen.
Wissen ist nicht alles. Man muss es auch anwenden können.
PS Fritz!Box API - TR-064 Schnittstelle | PS EventLogManager |