Nach Update auf Windows 10 wirft Datetime Parse/Tryparse eine Exception (Ländereinstellungen gleich)

Hallo zusammen,

ich habe ein komisches Problem. Ich habe von einem Kunden eine Rückmeldung bekommen, dass nach dem Update von Windows 8.1 auf Windows 10 er den Lizenzschlüssel nicht mehr verwenden kann. Die Stelle an der die Exception auftritt kenne ich. Dort wird mittels Parse und Tryparse Daten (Mehrzahl Datum) geprüft. Die Exception kenne ich leider nicht genau, weil der Kollege das in eine allgemeine Fehlermeldung abfängt.

Meine Forschungen ergaben jetzt, dass wenn ein System in einer anderen Sprache läuft wo z.B. das Zeitformat nicht hh:mm ist sondern z.b. hh.mm. Aber das trifft nicht zu. In dem System ist die Ländereinstellung Deutsch laut Kunde.

Hat jemand das schon gehabt?

Wir haben mehrere Kunden mit Windows 10.

Grüße

Eigentlich sollte die Windows Version keinen Unterschied machen.

Aber um ganz sicher zu gehen, kannst Du diese Infos doch explizit mit geben?
Für global gültige Daten würde ich CultureInfo.InvariantCulture verwenden.
Dann sind auch die Einstellungen im Windows egal.

Stell mal dein eigenes System auf Englisch um und prüfe deine Datumsroutinen. Sie sollten dann auch funktionieren.

Wir hatten mal bei Installation auf einem Apple Computer merkwürdige Datumseinstellungen im Windows.

Grüße Bernd

FxCop ist eine saubere Möglichkeit, wie man seinen Code auf solche Fehler automatisch prüft.

FxCop gibt es leider nur für das Framework 2.0.

Grüße Bernd

Wenn man Roslyn/VS 2015 benutzt, dann kann man sich das Nuget Package herunterladen und muss dann unter Code Analysis "Enable Code Analysis on Build" auswählen.

Nennt sich schon seit längerem "Code Analysis" und ist beim VS automatisch dabei: "Build -> Run Code Analysis on solution/<project>".

Hallo,

ich bin auch davon ausgegangen, dass die Windows Version keinen Unterschied macht. Doch leider ist es scheinbar so. Das Problem trat erst nach dem Update auf.

Aber um ganz sicher zu gehen, kannst Du diese Infos doch explizit mit geben?
Für global gültige Daten würde ich CultureInfo.InvariantCulture verwenden.
Dann sind auch die Einstellungen im Windows egal.

Da müsste ich ja das ganze Projekt durchsuchen und Änderungen vornehmen. Puhh. Ich hab gehofft das das über Windows lösbar ist.

Das Projekt läuft unter .Net 2.0. Ich schau mir eure Tipps morgen mal an.

grüße

Es betrifft doch nur den Lizenzschlüssel?

InvariantCulture solltest Du nur dort mit geben, wo Du es wirklich brauchst, also wenn die Daten nicht für den User sichtbar oder Sprachneutral sind
Z.B. wenn Du Daten in die Datenbank schreibst und die zwingend String sein müssen.
Oder wenn Du Daten sprachneutral in eine Datei schreibst
Oder bei einem Lizenzschlüssel, aus dem Werte geparst werden müssen

Für die Anzeige oder z.B. Excel-Exporte aber nicht, da sollte die Windows-Einstellung genommen werden.

Hallo,

ich hab jetzt durch ein Analysetool herrausgefunden das folgendes auf dem System des Kunden leer ist: System.Globalization.CultureInfo.CurrentCulture.DateTimeFormat.LongDatePattern
Bei uns wird da das angezeigt: dddd, d. MMMM yyyy

Was kann das sein?

Das LongDatePattern sollte einstellbar sein.
Systemsteuerung > Region > Formate > Datum (lang)

Das müsste dann ja auch leer sein (vielleicht durch ein Script der IT des Kunden überschrieben?) - vielleicht reicht es hier einmal auf Speichern zu drücken.

Öffne den Explorer und gibt folgendes als Pfad ein:
Systemsteuerung\Zeit, Sprache und Region
Auf "Region" klicken, darin auf "Weitere Einstellungen ..." und dort in den Reiter "Datum"

Wenn ich mich nicht irre, müsste das die Einstellung "Datum (lang)" unter "Datumsformate" sein.
Warum da nichts drin steht, kann ich aber auch nicht sagen, das sollte eigentlich gar nicht möglich sein. Wenn ich da nicht's oder Leerzeichen eintrage, wird immer der Default eingetragen.

Einzige Erklärung, die mir einfällt:
Irgendwas oder irgendwer hat diesen Wert nicht über die Settings sondern manuell in der Registry geändert, da kann natürlich nicht validiert werden. Warum das jemand tun sollte: Frag mich was leichteres 😄

Auf jeden Fall ist das ein Paradebeispiel, warum man immer konkret nach schauen sollte, ob und welche CultureInfo man angibt. Die Einstellungen von Windows sollten nur für Anzeige, Ausgabe und Ähnliches genutzt werden, nicht für Funktionen, von denen das System abhängt.

Guten Morgen zusammen,

wir haben jetzt die Rückmeldung, dass das tasächlich das Problem war.
Wir werden das ändern. Kann man das Global ihrgend wie mitgeben für das geamte Projekt, oder geht das nur darüber es bei jedem Parse oder TryParse mitzugeben? Global zuzuordnen scheint nicht zu gehen, die Attribute sind ja schreibgeschützt.

Grüße

Hallo neo,

wir haben damals in einem Projekt auf CultureInfo.InvariantCulture via StyleCop bzw. FxCop geprüft. Vielleicht kannst du sowas einrichten.

Gruss

Coffeebean

Du kannst CultureInfo.CurrentCulture bzw. CultureInfo.CurrentUICulture setzen.
Allerdings wird das auch überall anders verwendet, wie z.B. in WinForms oder WPF.

Die einzig richtige Herangehensweise, ist, dass Du überall, wo Du Sprachunabhängigkeit brauchst, diese auch explizit anforderst, indem Du CultureInfo.InvariantCulture mit gibst.

Also Nein, es gibt keine Möglichkeit.
Du kannst dir nur, wie Coffeebean schon schreibt, von Tools die Arbeit erleichtern lassen, also z.B. die Aufrufe heraus suchen lassen. Empfehlen kann ich da aber leider nichts.